Contractuele bron. Deze pagina wordt tijdens de website-build rechtstreeks gegenereerd uit de canonieke verwerkersovereenkomst en de onlosmakelijke bijlagen A, B en C in de 2LZ-documentatie.
Verwerkersovereenkomst (AVG art. 28)
Model dat 2LZ B.V. aanbiedt aan haar klanten. Maakt onderdeel uit van de overeenkomst tussen 2LZ en de klant. Versie: 1.6 — 2026-07-17.
Partijen
Verwerker: 2LZ B.V., KvK 42022298, gevestigd te Griendakker 22, 2809 RR Gouda. Contactpersoon AVG: Alain Matthieu Vacquier.
Contactkanalen:
- Privacy-/AVG-verzoeken: privacy@2lz.ai
- Datalekmeldingen / beveiligingsincidenten: security@2lz.ai
Verwerkingsverantwoordelijke ("Klant"): de rechtspersoon die met 2LZ een overeenkomst sluit voor het gebruik van het 2LZ-platform, zoals geïdentificeerd in de hoofdovereenkomst.
Contractgegevens Klant:
- Statutaire naam: [invullen]
- KvK-nummer: [invullen]
- Vestigingsadres: [invullen]
- Vertegenwoordigd door: [naam en functie/bevoegdheid]
- Privacycontact: [naam/e-mailadres]
- Referentie hoofdovereenkomst/order: [invullen]
- Ingangsdatum: [invullen; bij ontbreken gelijk aan de ingangsdatum van de hoofdovereenkomst]
De Klant is verwerkingsverantwoordelijke voor de persoonsgegevens die hij via het platform verwerkt (o.a. van zijn medewerkers en relaties). 2LZ verwerkt deze gegevens uitsluitend als verwerker, in opdracht van de Klant.
1. Voorwerp en instructies
1.1 2LZ verwerkt persoonsgegevens uitsluitend op gedocumenteerde instructie van de Klant, voor de in Bijlage A beschreven doeleinden, en niet voor eigen doeleinden. 1.2 Het gebruik van het platform conform de documentatie geldt als instructie. Aanvullende instructies moeten redelijk en technisch uitvoerbaar zijn; 2LZ mag voor het uitvoeren van aanvullende instructies die buiten de normale dienstverlening vallen kosten in rekening brengen tegen de alsdan geldende tarieven. 1.3 2LZ stelt de Klant onverwijld in kennis indien een instructie naar haar oordeel in strijd is met de AVG of andere toepasselijke gegevensbeschermingswetgeving, en is niet gehouden een instructie uit te voeren die naar haar oordeel onrechtmatig is. 1.4 Indien Unierecht of Nederlands recht 2LZ verplicht persoonsgegevens anders dan op instructie van de Klant te verwerken, informeert 2LZ de Klant vóór die verwerking over dat wettelijk voorschrift, tenzij die wetgeving deze kennisgeving om gewichtige redenen van algemeen belang verbiedt. 2LZ beperkt de verwerking tot wat wettelijk noodzakelijk is en legt de grondslag en omvang daarvan vast. 1.5 2LZ verkoopt de persoonsgegevens niet, gebruikt deze niet voor reclame aan betrokkenen en combineert deze niet met gegevens uit andere bronnen voor eigen profilering. Verwerkingen waarvoor 2LZ zelf doel en middelen bepaalt, vallen buiten deze verwerkersovereenkomst en worden afzonderlijk in de privacyverklaring verantwoord.
2. Aard, duur, categorieën
De aard en het doel van de verwerking, de categorieën betrokkenen en persoonsgegevens, en de bewaartermijnen zijn beschreven in Bijlage A. De verwerking duurt voort zolang de hoofdovereenkomst van kracht is.
2LZ kan in opdracht van de Klant bijzondere persoonsgegevens verwerken, in het bijzonder beperkte gegevens over ziekteverzuim. De Klant bepaalt en documenteert zowel de grondslag van artikel 6 AVG als de toepasselijke uitzondering van artikel 9 lid 2 AVG en de UAVG. De actieve verzuimfunctionaliteit verwerkt het ziektefeit, noodzakelijke datums en duur, status en beperkte plannings-/verwerkingsmetadata; zij vraagt niet naar diagnose, symptomen, oorzaak, artsinformatie of een medisch dossier en bevat geen vrij tekstveld voor medische of HR-notities.
3. Beveiliging (art. 32)
3.1 2LZ treft passende technische en organisatorische maatregelen, beschreven in Bijlage C. Deze omvatten onder meer versleuteling (in transport en at-rest), multi-tenant-isolatie, toegangscontrole (RBAC, MFA), audit-logging, back-up/herstel en hardening. 3.2 2LZ evalueert de maatregelen periodiek en houdt Bijlage C actueel. 2LZ mag de maatregelen wijzigen mits het beveiligingsniveau niet wezenlijk wordt verlaagd; de Klant wordt over wezenlijke wijzigingen geïnformeerd.
4. Vertrouwelijkheid en geheimhouding
4.1 2LZ verplicht eenieder die onder haar gezag toegang heeft tot de persoonsgegevens tot geheimhouding, of bindt hen aan een passende wettelijke geheimhoudingsplicht. De toegang is beperkt tot personen voor wie die noodzakelijk is voor de uitvoering van hun werkzaamheden (need-to-know). 4.2 Partijen behandelen alle informatie die zij in het kader van deze overeenkomst van elkaar ontvangen als vertrouwelijk, voor zover deze als vertrouwelijk is aangemerkt of redelijkerwijs als vertrouwelijk moet worden beschouwd. De geheimhoudingsplicht geldt niet voor informatie die:
algemeen bekend is of wordt zonder toedoen van de ontvangende Partij;
reeds rechtmatig in het bezit was van de ontvangende Partij voordat deze werd verstrekt;
rechtmatig is verkregen van een derde die niet aan geheimhouding was gebonden;
openbaar moet worden gemaakt op grond van een wettelijke verplichting.
4.3 De geheimhoudingsplicht blijft van kracht gedurende de looptijd van deze overeenkomst en gedurende vijf jaar na beëindiging daarvan. Voor persoonsgegevens, bedrijfsgeheimen en informatie die naar haar aard blijvend vertrouwelijk is, blijft de geheimhoudingsplicht gelden zolang die informatie haar vertrouwelijke karakter behoudt of toepasselijk recht bescherming voorschrijft.
5. Subverwerkers (art. 28 lid 2/4)
5.1 De Klant geeft algemene toestemming voor het inschakelen van subverwerkers, opgenomen in Bijlage B. 5.2 2LZ legt elke subverwerker ten minste dezelfde verplichtingen op als in deze overeenkomst, en blijft jegens de Klant volledig verantwoordelijk voor de nakoming door subverwerkers. 5.3 2LZ informeert de Klant in beginsel ten minste 30 dagen vooraf over een voorgenomen toevoeging of vervanging van een subverwerker. De Klant kan binnen die termijn gemotiveerd bezwaar maken op zwaarwegende, objectieve gronden die verband houden met gegevensbescherming. Is voorafgaande kennisgeving wegens een spoedeisende beveiligings- of continuïteitsreden niet mogelijk, dan informeert 2LZ de Klant zo spoedig mogelijk met motivering. Komen Partijen er niet uit, dan kan de Klant de hoofdovereenkomst beëindigen voor zover die op de betreffende verwerking ziet.
6. Doorgifte naar derde landen
Doorgifte of verwerking buiten de EER vindt uitsluitend plaats zoals beschreven in Bijlage B en met een mechanisme uit hoofdstuk V AVG. Het EU-VS Data Privacy Framework wordt alleen gebruikt voor een daadwerkelijk gecertificeerde Amerikaanse juridische entiteit en een dienst die onder die certificering valt. Anders gebruikt 2LZ onder meer de toepasselijke module van de standaardcontractbepalingen, een doorgiftebeoordeling en waar nodig aanvullende maatregelen. Primaire platformopslag blijft in beginsel binnen de EU (AWS, Ierland — eu-west-1), maar dit sluit functie-afhankelijke internationale verwerking niet uit.
7. Bijstand aan de Klant (art. 28 lid 3 sub e/f)
7.1 Rechten van betrokkenen (art. 15–22): 2LZ stelt functionaliteit beschikbaar voor inzage/export (data-portabiliteit), rectificatie en anonimisering/verwijdering, en ondersteunt de Klant bij verzoeken die hij niet zelf via het platform kan afhandelen. Ontvangt 2LZ zelf een verzoek van een betrokkene, dan stuurt zij dit onverwijld door naar de Klant en reageert zij niet zelfstandig, tenzij de Klant daartoe uitdrukkelijk instrueert. 7.2 DPIA (art. 35): de DPIA voor de verwerkingen van de Klant is diens verantwoordelijkheid. 2LZ verstrekt het DPIA-ondersteuningsdocument met de feitelijke bouwstenen (verwerkingen, maatregelen, restrisico's). 7.3 Beveiligings-/meldplichtbijstand (art. 32–36): 2LZ verleent redelijke bijstand. Voor aanvullende werkzaamheden die aantoonbaar buiten de standaarddienstverlening vallen, mag 2LZ redelijke kosten in rekening brengen tegen de alsdan geldende tarieven. Dit laat tijdige bijstand die 2LZ op grond van artikel 28 lid 3 AVG verplicht moet verlenen onverlet.
7.4 Bijzondere gegevens, monitoring en signalering: de Klant is verantwoordelijk voor een geldige grondslag, werknemersinformatie, medezeggenschap en een DPIA waar vereist voor ziekteverzuim, locatiemonitoring en andere werknemersanalyse. De verzuimmodule kan uitsluitend een on-demand feitelijke telling tonen wanneer een werknemer binnen twaalf maanden ten minste drie afzonderlijke ziekmeldingen heeft. Deze technische standaard is geen wettelijke norm, bevat geen risicoscore of medische duiding en heeft geen automatisch gevolg. De Klant legt het gebruik en de drempel vast in het ziekteverzuimbeleid, beoordeelt OR/PVT-instemming en gebruikt het signaal alleen als aanleiding voor een ondersteunend gesprek. Het signaal mag niet zelfstandig leiden tot loon-, disciplinaire, ontslag-, controle-, medische of re-integratiebesluiten. Een technische toestemmingshandeling in het platform bewijst niet dat toestemming in de arbeidsrelatie vrij is gegeven.
8. Datalekken (art. 33)
8.1 2LZ meldt een inbreuk in verband met persoonsgegevens zonder onredelijke vertraging, en waar mogelijk binnen 48 uur na kennisneming, aan de Klant, met de informatie die de Klant nodig heeft om aan zijn meldplicht (72-uurstermijn richting de AP) te voldoen. 8.2 De melding omvat ten minste, voor zover bekend: de aard van de inbreuk; de categorieën en het (geschatte) aantal betrokkenen en records; de mogelijke gevolgen; en de getroffen en voorgestelde maatregelen. Aanvullende informatie volgt zodra beschikbaar (gefaseerde melding). 8.3 De meldketen en procedure zijn beschreven in de Datalek-procedure (intern bij 2LZ). De Klant beoordeelt zelf of melding aan de AP en/of betrokkenen vereist is. 2LZ verleent op verzoek redelijke medewerking bij het onderzoek. Een door de Klant zelf via API/webhooks of als implementatiepartner ingeschakelde externe partij valt niet onder de verantwoordelijkheid van 2LZ als subverwerker, maar wanneer 2LZ kennis krijgt van een inbreuk die de via het platform verwerkte of overgedragen persoonsgegevens kan raken, informeert 2LZ de Klant overeenkomstig dit artikel.
9. Audit (art. 28 lid 3 sub h)
9.1 2LZ toont naleving aan via deze overeenkomst, Bijlage C en (op verzoek) beschikbare verklaringen/rapportages. Wanneer voor 2LZ een geldig ISO 27001-certificaat, SOC 2 Type II-rapport of gelijkwaardig onafhankelijk auditrapport beschikbaar is, kan 2LZ dit in plaats van een audit ter plaatse verstrekken. Het ontbreken van zo'n certificering wordt niet als certificering gepresenteerd en laat het auditrecht uit artikel 9.2 onverlet. 9.2 De Klant mag zelf of door een door hem gemachtigde onafhankelijke auditor, met redelijke aankondiging (ten minste 30 dagen) en in beginsel niet vaker dan jaarlijks, een audit uitvoeren tijdens kantooruren, met inachtneming van de vertrouwelijkheid en bedrijfsvoering van 2LZ en de vertrouwelijkheid van gegevens van andere klanten. De beperking in frequentie en aankondigingstermijn geldt niet bij een gegrond vermoeden van een ernstige tekortkoming, na een relevante ernstige inbreuk, wanneer een toezichthouder dit verlangt of wanneer dwingend recht een kortere termijn vereist. Een externe auditor is gebonden aan ten minste even strenge geheimhouding. 9.3 De redelijke kosten van een reguliere audit ter plaatse komen voor rekening van de Klant; 2LZ mag voor redelijke interne uren het alsdan geldende tarief in rekening brengen. 2LZ brengt deze kosten niet in rekening voor zover de audit noodzakelijk is geworden door een aan 2LZ toerekenbare ernstige inbreuk of een materiële tekortkoming van 2LZ aantoont. Wettelijke onderzoeks- en auditbevoegdheden van een toezichthouder worden niet beperkt.
10. Einde en teruggave/verwijdering
10.1 Gedurende de looptijd kan de Klant te allen tijde via het platform een export van de persoonsgegevens maken. 10.2 Bij beëindiging geldt één herstel- en exportperiode van maximaal 30 dagen. Wanneer de Algemene Voorwaarden vóór de beëindiging al een herstel- en exportperiode van 30 dagen hebben geboden, geldt diezelfde periode tevens als de exportperiode onder dit artikel en begint geen nieuwe periode. De Klant kan 2LZ vóór het einde van de toepasselijke periode schriftelijk instrueren de persoonsgegevens eerder te retourneren of te verwijderen. Geeft de Klant geen tijdige keuze door, dan geldt verwijdering als gedocumenteerde standaardinstructie. Na afloop verwijdert 2LZ de actieve operationele persoonsgegevens en resterende productiekopieën zonder onredelijke vertraging; een aanvullende productie-bewaartermijn van 90 dagen geldt niet. Een bewaarplicht van de Klant leidt alleen tot verdere verwerking door 2LZ wanneer de Klant daartoe vóór verwijdering een specifieke gedocumenteerde instructie geeft en die instructie rechtmatig is.
10.3 Persoonsgegevens in back-ups zijn afgescheiden van regulier gebruik, worden niet voor andere doelen verwerkt en vervallen volgens een technische herstelcyclus van maximaal 30 dagen. Een herstel mag eerder verwijderde persoonsgegevens niet opnieuw in regulier gebruik brengen; na een herstel wordt de verwijderingsinstructie opnieuw toegepast. Unierecht of Nederlands recht dat 2LZ zelf tot bewaring verplicht en een specifieke, rechtsgeldige legal hold gaan alleen voor zover noodzakelijk voor. Minimale fiscale, contractuele en beveiligingsbewijzen die 2LZ als zelfstandig verwerkingsverantwoordelijke op een afzonderlijke grondslag bewaart, vallen buiten deze verwerkersovereenkomst, blijven afgescheiden en worden niet voor andere doelen gebruikt. Op verzoek bevestigt 2LZ de uitvoering van de verwijdering schriftelijk.
11. Aansprakelijkheid en vrijwaring
11.1 De aansprakelijkheid van 2LZ voor schade die voortvloeit uit of verband houdt met deze overeenkomst volgt de regeling in de hoofdovereenkomst. 11.2 Bevat de hoofdovereenkomst geen regeling, dan is de totale aansprakelijkheid van 2LZ jegens de Klant per kalenderjaar beperkt tot het bedrag dat de Klant in de twaalf maanden voorafgaand aan de schadeveroorzakende gebeurtenis aan 2LZ heeft betaald, met een maximum van € 50.000,- (vijftigduizend euro). 11.3 Onverminderd artikel 11.5 is 2LZ niet aansprakelijk voor schade voor zover die uitsluitend is veroorzaakt door:
het niet naleven van de AVG door de Klant of een aantoonbaar onrechtmatige instructie van de Klant, voor zover 2LZ overeenkomstig artikel 1.3 heeft gehandeld;
een externe partij die de Klant zelf via API/webhooks of als partner heeft ingeschakeld, voor zover geen tekortkoming van 2LZ aan het ontstaan of de omvang van de schade heeft bijgedragen;
indirecte schade, waaronder gederfde winst, gemiste besparingen en reputatieschade, voor zover een dergelijke uitsluiting volgens dwingend recht is toegestaan.
11.4 De Klant vrijwaart 2LZ tegen aanspraken van derden, waaronder betrokkenen, voor zover die aanspraken uitsluitend voortvloeien uit een aan de Klant toerekenbare onrechtmatige verwerking, een onrechtmatige instructie of het handelen van een door de Klant zelf ingeschakelde externe partij. Deze vrijwaring geldt niet voor zover een tekortkoming van 2LZ aan de aanspraak heeft bijgedragen. De interne draagplicht voor bestuurlijke boetes wordt uitsluitend geregeld in artikel 12. 11.5 Niets in deze overeenkomst beperkt de rechten van betrokkenen, de bevoegdheden van de toezichthouder of aansprakelijkheid die op grond van dwingend recht niet contractueel kan worden beperkt. 11.6 De beperkingen en uitsluitingen in dit artikel gelden niet bij opzet of bewuste roekeloosheid van het leidinggevend personeel van de aansprakelijke Partij of voor zover dwingend recht anders bepaalt.
12. Boetes van toezichthouders
12.1 Legt een toezichthouder een boete op in verband met de verwerking onder deze overeenkomst, dan geldt:
veroorzaakt uitsluitend door een tekortkoming van 2LZ: 2LZ draagt de boete;
veroorzaakt uitsluitend door een tekortkoming van de Klant: de Klant draagt de boete;
veroorzaakt door tekortkomingen van beide Partijen: ieder draagt naar rato van zijn bijdrage aan de tekortkoming.
12.2 Partijen verlenen elkaar redelijke medewerking bij het voeren van verweer tegen boetes en andere handhavingsmaatregelen.
12.3 De interne draagplicht in dit artikel bindt de toezichthouder of betrokkenen niet en beperkt geen rechtstreeks uit de AVG voortvloeiende aansprakelijkheid of bevoegdheid.
13. Toepasselijk recht en geschillen
13.1 Op deze overeenkomst is Nederlands recht van toepassing. 13.2 Geschillen die voortvloeien uit of verband houden met deze overeenkomst worden voorgelegd aan de bevoegde rechter van de rechtbank Den Haag, tenzij dwingend recht anders voorschrijft.
14. Slotbepalingen
14.1 Bij strijd tussen deze overeenkomst en de hoofdovereenkomst prevaleert deze verwerkersovereenkomst voor zover het de verwerking van persoonsgegevens betreft. 14.2 Wijzigingen zijn slechts geldig indien schriftelijk overeengekomen. 2LZ mag Bijlage B actualiseren volgens artikel 5.3 en Bijlage C wijzigen volgens artikel 3.2. Bijlage A mag zonder afzonderlijke instemming alleen worden aangepast om een reeds overeengekomen tenantkeuze, wettelijke verplichting of aantoonbare technische verduidelijking correct te beschrijven; een nieuw verwerkingsdoel of een materiële uitbreiding van gegevenscategorieën vereist voorafgaande schriftelijke overeenstemming. 14.3 Is een bepaling nietig of vernietigbaar, dan blijven de overige bepalingen van kracht en treden Partijen in overleg over een vervangende bepaling die de strekking zo dicht mogelijk benadert. 14.4 Deze overeenkomst kan op papier, met een gekwalificeerde of andere rechtsgeldige elektronische handtekening, of door een aantoonbare elektronische aanvaardingshandeling bij het sluiten van de hoofdovereenkomst worden gesloten. Elektronische exemplaren en afzonderlijk ondertekende exemplaren gelden gezamenlijk als één overeenkomst. 14.5 Deze overeenkomst treedt in werking op de bij de Klantgegevens genoemde ingangsdatum of, wanneer die ontbreekt, gelijktijdig met de hoofdovereenkomst. Zij blijft van kracht zolang 2LZ persoonsgegevens namens de Klant verwerkt, ook indien de hoofdovereenkomst eerder eindigt.
Bijlagen (onlosmakelijk onderdeel):
- Bijlage A — Verwerkingen, gegevenscategorieën en bewaartermijnen
- Bijlage B — Subverwerkers-register
- Bijlage C — Technische en organisatorische maatregelen, art. 32
Ondertekening
Door ondertekening of aantoonbare elektronische aanvaarding verklaren Partijen bevoegd te zijn en deze verwerkersovereenkomst, inclusief Bijlagen A, B en C, te aanvaarden.
2LZ B.V.
- Naam: Alain Matthieu Vacquier
- Hoedanigheid/bevoegdheid: rechtsgeldig vertegenwoordigd door haar zelfstandig bevoegde bestuurder Vacquier Holding B.V., op haar beurt rechtsgeldig vertegenwoordigd door haar zelfstandig bevoegde bestuurder Alain Matthieu Vacquier
- Plaats: Gouda
- Datum: [invullen]
- Handtekening / elektronische aanvaarding: [invullen of systeemregistratie]
Klant
- Statutaire naam: [invullen]
- Naam vertegenwoordiger: [invullen]
- Hoedanigheid/bevoegdheid: [invullen]
- Plaats: [invullen]
- Datum: [invullen]
- Handtekening / elektronische aanvaarding: [invullen of systeemregistratie]
Dit model is afgestemd op de op 16 juli 2026 geïnventariseerde verwerking. Feitelijke platforminstellingen, contracten met subverwerkers en doorgiftemechanismen moeten operationeel aantoonbaar blijven. Bij materiële platform- of leverancierswijzigingen worden de bijlagen vóór activering bijgewerkt.
Bijlage A — Verwerkingen, gegevenscategorieën en bewaartermijnen
Bij: Verwerkersovereenkomst 2LZ B.V. (verwerker) ↔ Klant (verwerkingsverantwoordelijke) Versie: 1.6 — 17 juli 2026 Feitelijke basis: code- en documentinventaris van 17 juli 2026. Productieconfiguratie en tenantkeuzes kunnen functies in- of uitschakelen.
1. Onderwerp, aard en duur
2LZ levert een multi-tenant SaaS-platform en mobiele applicatie voor personeels-, planning-, werk-, veiligheids-, klant-, facturatie- en integratiefuncties. De verwerking bestaat uit verzamelen, vastleggen, structureren, raadplegen, wijzigen, analyseren, verzenden, beschikbaar stellen, beveiligen, exporteren, archiveren, anonimiseren en verwijderen.
2LZ verwerkt de hieronder beschreven persoonsgegevens uitsluitend op gedocumenteerde instructie van de Klant en gedurende de looptijd plus de in de verwerkersovereenkomst afgesproken export-, back-up- en verwijdertermijnen.
2. Categorieën betrokkenen
- werknemers, uitzendkrachten en andere gebruikers die de Klant toegang geeft;
- beheerders, planners, HR- en kantoormedewerkers van de Klant;
- sollicitanten voor zover de Klant hun gegevens in het platform invoert;
- contactpersonen, klanten en leveranciers van de Klant;
- bezoekers of ondertekenaars die via een klantproces gegevens aanleveren;
- gebruikers van gekoppelde externe accounts of apparaten.
3. Categorieën verwerkingen en gegevens
| Verwerking | Hoofdcategorieën persoonsgegevens | Doel in opdracht van de Klant | Bijzonder/hoog risico |
|---|---|---|---|
| Gebruikers- en personeelsadministratie | naam, adres, contactgegevens, geboortedatum, personeelsnummer, functie, contract- en roostergegevens, IBAN, noodcontact, kledingmaten, kenteken, vaardigheden en certificaten | accountbeheer, personeelsadministratie, planning, communicatie en salaris-/HR-ondersteuning | kan gevoelige financiële en identiteitsgegevens bevatten |
| Authenticatie en beveiliging | wachtwoordhash, MFA-geheim, sessie-/apparaatgegevens, IP-adres, user-agent, login- en risicosignalen | toegangsbeveiliging, misbruik- en fraudepreventie | profilering voor beveiliging; blokkadebesluiten moeten controleerbaar zijn |
| Ziekteverzuim en inzetbaarheid | werknemer-ID en naam, meld-, ziek- en hersteldatum, verwachte/berekende duur, status, verwerkingsmoment en optionele projectreferentie voor het overnemen van lopend werk | registreren dat iemand afwezig en niet inplanbaar is, herstel registreren en noodzakelijke operationele opvolging | gezondheidsgegevens, art. 9 AVG. De actieve module vraagt niet naar en toont geen diagnose, symptomen, oorzaak, artsbezoek, verpleegadres, telefoonnummer, werkgerelateerdheid of medische/HR-vrije tekst |
| Neutraal gesprekssignaal bij herhaalde ziekmelding | werknemer-ID en naam en het aantal afzonderlijke ziekmeldingen in een voortschrijdende periode van 12 maanden | bevoegde klantgebruikers attenderen dat volgens het vastgestelde verzuimbeleid een ondersteunend gesprek kan worden overwogen | on-demand feitelijke telling bij standaarddrempel 3; geen Bradford-/risicoscore, voorspelling, dag-/seizoenspatroon, teamvergelijking, opslag van een profiel of automatisch gevolg. De drempel is geen wettelijke norm |
| Verlof, beschikbaarheid en roosters | verlofsoort, periode, reden, vervanger, beschikbaarheid, planning en goedkeuring | verlofbeheer, inzetbaarheid en planning | redenen kunnen onbedoeld gevoelige informatie bevatten |
| Werkbonnen en activiteiten | tijden, project/klant, materialen, foto's, opmerkingen, handtekening, GPS klant-/ondertekenlocatie, device-info | uitvoering, bewijs, facturatie en VCA/LMRA/TRA | locatie en handtekening; vrije tekst/foto's kunnen bijzondere gegevens bevatten |
| Declaraties en onkosten | bedrag, btw, bon, OCR-resultaat, bank-/betaalgegevens en goedkeuring | vergoeding en financiële administratie | financiële gegevens; OCR kan extra inhoud uitlezen |
| Live locatie “Wie is Waar” en SOS | user-ID, GPS, nauwkeurigheid, snelheid, tijdstip, check-in/-out, apparaat en SOS-inhoud | operationele planning, veiligheid en noodhulp | stelselmatige werknemersmonitoring; DPIA, proportionaliteit en medezeggenschap beoordelen |
| Rittenregistratie en routecontrole | gebruiker, voertuig/kenteken, vertrek/aankomst, GPS, adressen, kilometers, passagiers, afwijkings- en fraudesignalen | ritten-, kilometer- en fiscale administratie | profilering; code berekent requiresReview en een legacy autoReject-hoogrisico-indicator, maar voert zelf geen afwijzing uit. Geen nadelig besluit zonder betekenisvolle menselijke beoordeling |
| Personeelsdocumenten | VCA, diploma, rijbewijs, ID/werkvergunning, trainingscertificaat, salarisstrook en metadata | document-, geldigheids- en compliancebeheer | kopie-ID en salarisgegevens zijn gevoelig. Medisch attest/medische keuring is geen toegestaan regulier documenttype |
| Klanten en contactpersonen | naam, rol, e-mail, telefoon, adressen, communicatievoorkeuren, KvK/btw en salesgegevens | CRM, communicatie, planning en facturatie | gegevens van eenmanszaken kunnen persoonsgegevens zijn |
| E-mail, agenda en vergaderingen | OAuth-tokens, provider-e-mail, e-mailinhoud, agenda-items, deelnemers en vergaderlinks | door de gebruiker geactiveerde synchronisatie en communicatie | externe providerverwerking en mogelijke derde-landdoorgifte |
| Pushnotificaties | push-token, user-ID, titel, bericht en deeplink-/contextdata | notificaties aan mobiele gebruikers | inhoud moet worden geminimaliseerd vanwege lockscreenweergave en externe pushketen |
| AI-assistent en tekstanalyse | afhankelijk van de functie: offerte-/klantgegevens, werkbontekst, beschrijvingen, prijzen en gebruikersprompt | suggesties, samenvatting, vergelijking en tekstgeneratie | externe AI-verwerking; persoonsgegevens minimaliseren en functies alleen activeren na leveranciers-/doorgiftecontrole |
| Spraaktranscriptie | audiobestand, gesproken inhoud en transcript | door gebruiker gevraagde omzetting van spraak naar tekst | kan vrije tekst en bijzondere gegevens bevatten; alleen functie-afhankelijk. Ziekteverzuim is geen toegestaan transcriptiedoel |
| Externe geocoding en routing | adressen, coördinaten, routepunten en tijdstippen | adresvalidatie, route- en afstandsberekening | locatiegegevens; provider en land zijn functie-afhankelijk |
| Salaris-/ERP-koppelingen | werknemersreferenties, uren, verlof, loon-/exportgegevens en tokens, afhankelijk van connector | overdracht op instructie aan AFAS, Nmbrs, Loket of andere gekozen ontvanger | klantgerichte externe verstrekking; rol en contract per connector vastleggen |
| Audit, logging en exports | user-ID, actie, IP, user-agent, oude/nieuwe waarde, exportinhoud en beveiligingsgebeurtenis | beveiliging, accountability, rechtenafhandeling en incidentonderzoek | logging mag geen onnodige inhoud of geheimen bevatten |
4. Bijzondere persoonsgegevens en verboden inhoud
Het feit dat een werknemer ziek is, de duur van het verzuim en een daarop gebaseerde frequentietelling zijn gegevens over gezondheid. Het beperken van velden verlaagt het risico, maar maakt de resterende verwerking niet tot gewone persoonsgegevens.
De Klant:
- bepaalt en documenteert een grondslag van art. 6 AVG én een uitzondering van art. 9 lid 2 AVG/UAVG;
- verwerkt alleen de beperkte gegevens die een werkgever volgens Nederlands recht mag registreren;
- laat medische beoordeling en medische dossiers bij de bedrijfsarts/arbodienst;
- instrueert gebruikers om geen symptomen, diagnose, oorzaak of artsinformatie via andere platformvelden, documenten, imports of integraties toe te voegen;
- beperkt toegang tot medewerkers met een aantoonbare taak;
- voert waar vereist een DPIA uit.
2LZ verwerkt geen BSN als regulier gestructureerd personeelsveld. Als een door de Klant geüpload document of vrije tekst toch BSN of andere verboden gegevens bevat, blijft de Klant verantwoordelijk voor de rechtmatigheid van de upload en ondersteunt 2LZ verwijdering op instructie.
Historische ziekteverzuimrecords kunnen nog versleutelde legacyvelden bevatten die vóór deze minimalisatie zijn ingevoerd. De actieve publieke API en gebruikersinterface geven deze velden niet terug en nieuwe meldingen vullen ze niet. Verwijdering of anonimisering van bestaande productiegegevens gebeurt uitsluitend na tenantinstructie, gecontroleerde dry-run, controle op wettelijke uitzonderingen of legal holds en afzonderlijk productieakkoord.
5. Grondslagen en verantwoordelijkheden
De Klant bepaalt als verwerkingsverantwoordelijke de doeleinden en grondslagen. Deze bijlage verleent geen zelfstandige grondslag. Mogelijke grondslagen hangen af van de concrete inzet:
- uitvoering van arbeids- of andere overeenkomsten, voor zover de verwerking daarvoor objectief noodzakelijk is;
- wettelijke verplichting met een concrete wettelijke bron;
- gerechtvaardigd belang na een gedocumenteerde noodzaak-, proportionaliteits- en belangenafweging;
- toestemming alleen wanneer deze werkelijk vrij, specifiek, geïnformeerd en intrekbaar is.
In de arbeidsrelatie is toestemming wegens de machtsverhouding doorgaans geen geschikte hoofdgrondslag voor structurele locatie- of prestatiemonitoring. De technische locatiebevestiging in 2LZ is een controle- en transparantiemaatregel, geen garantie dat aan art. 6/7 AVG is voldaan.
6. Signalen, profilering en geautomatiseerde besluiten
Voor ziekteverzuim toont het platform uitsluitend een op verzoek berekende feitelijke meldingentelling: standaard een gesprekssignaal bij drie of meer afzonderlijke ziekmeldingen in de voorafgaande twaalf maanden. Het signaal bevat geen medische gevolgtrekking, risicolabel of voorspelling, wordt niet als afzonderlijk profiel opgeslagen en veroorzaakt geen automatische actie. De Klant stelt de toepassing en drempel vast in een transparant ziekteverzuimbeleid, informeert werknemers vooraf, beperkt toegang, beoordeelt OR/PVT-instemming en legt de grondslag en noodzakelijkheid vast.
Persoonlijke ziektepercentages, verzuimfrequentie en het gesprekssignaal worden niet verwerkt in de medewerkersprestatie- of totaalscore. Geaggregeerde verzuimpercentages op organisatie- of teamniveau blijven beschikbaar voor rechtmatig verzuimbeleid, zonder individuele rangschikking.
De Klant gebruikt het gesprekssignaal alleen als aanleiding voor een open, ondersteunend gesprek over werk en inzetbaarheid. Het is geen bewijs van misbruik en mag niet zelfstandig leiden tot controle, loonopschorting, disciplinaire maatregel, ontslag of een medische of re-integratiebeoordeling. Voor medische beoordeling schakelt de Klant de bedrijfsarts/arbodienst in.
Andere platformfuncties kunnen loginrisico's, ritafwijkingen en andere scores berekenen. Een score of vlag mag niet zonder een afzonderlijke art. 22-beoordeling en betekenisvolle menselijke tussenkomst als enige grond dienen voor een besluit met rechtsgevolg of vergelijkbaar aanmerkelijk gevolg.
7. Bewaartermijnen en huidige technische defaults
De Klant instrueert 2LZ per gegevenscategorie over een termijn die noodzakelijk en aantoonbaar is. Een fiscale bewaarplicht geldt alleen voor gegevens die werkelijk tot de fiscale administratie behoren en rechtvaardigt geen algemene bewaring van complete personeels- of gezondheidsdossiers.
| Datasoort | Juridische beleidslijn | Huidige technische default/maximale instelling bij ontbreken tenantbeleid |
|---|---|---|
| Actieve gebruikersgegevens | zolang account/dienstverband en doel bestaan; daarna per veld of dossiercategorie verwijderen/anonimiseren | 2555 dagen; moet vóór productiegebruik per tenant juridisch worden beoordeeld en waar nodig verkort |
| Ziekteverzuim | niet langer dan nodig. De AP noemt voor administratieve verzuimgegevens van de werkgever maximaal 2 jaar na einde arbeidsrelatie en voor een afgerond re-integratiedossier in beginsel 2 jaar na afronding; specifieke regels gelden onder meer bij eigenrisicodragerschap en geschillen | Privacyvriendelijke platformdefault: 730 dagen vanaf recoveryDate voor het reguliere SICK_LEAVE-record. Dit is geen wettelijke termijn. Actieve dossiers en dossiers zonder aantoonbare hersteldatum worden conservatief niet automatisch verwijderd; een afwijkende tenantinstructie moet doel en uitzondering documenteren |
| Verzuimaggregaten en gesprekssignaal | niet langer dan de onderliggende rechtmatig bewaarde verzuimgegevens | aggregaten en het gesprekssignaal worden on-demand berekend; geen afzonderlijke score- of signaalhistorie |
| Verlofaanvragen | per doel en eventueel fiscale/loonadministratieve relevantie; redenen eerder verwijderen wanneer niet meer nodig | 2555 dagen; per tenant beoordelen |
| Werkbonnen/factuuronderbouwing | 7 jaar voor zover onderdeel van de fiscale basisadministratie; overige inhoud korter | 2555 dagen |
| Declaraties en fiscale documenten | 7 jaar voor zover onderdeel van de fiscale basisadministratie | 2555 dagen |
| Live locatie “Wie is Waar” | zo kort mogelijk; 90 dagen is een maximum, geen automatisch rechtmatige standaard | 90 dagen |
| Rittenregistratie | 7 jaar voor fiscaal noodzakelijke ritgegevens; ruwe GPS eerder verwijderen/anonimiseren wanneer niet noodzakelijk | 2555 dagen; GPS-anonimisering na 5 jaar volgens huidige service |
| Notificaties | operationeel kort | 90 dagen |
| Toegangslogs | beveiligingsbehoefte en risico; periodiek herbeoordelen | maximaal 365 dagen; langer alleen voor een concreet incident of specifieke, tijdgebonden legal hold |
| Activiteitslogs | alleen zolang noodzakelijk voor het beschreven tenantdoel; geen onveranderbare 7-jaarskopie | 365 dagen en verwijdering volgens de tenant-exitprocedure |
| Gewone tenant-auditlogs | uitsluitend voor tenantaccountability en ondersteuning; ISO/SOC is niet zelfstandig een wettelijke bewaarplicht van 7 jaar | maximaal 730 dagen in tenantgebonden opslag; geen kopie naar de onveranderbare security- of fiscale evidencebucket; verwijdering bij tenant-exit na de ene herstel-/exportperiode |
| Minimaal beveiligingsbewijs 2LZ | afzonderlijke verwerking door 2LZ als verwerkingsverantwoordelijke voor platform- en informatiebeveiliging; geen werknemersprestatie- of HR-doel | maximaal 365 dagen; uitsluitend event-ID/tijd, gepseudonimiseerde tenant-, actor- en resourcereferenties, actie, resource, ernst/succes en alleen indien voor het security-event aanwezig het IP-adres; geen naam, e-mail, user-agent, locatie, businesspayload of wijzigingsdetails |
| Fiscaal/contractueel eventbewijs 2LZ | afzonderlijk en minimaal als aanvullend integriteitsbewijs bij klantfactuur- en contractgebeurtenissen; geen algemene grond voor tenantactiviteit en geen vervanging van het onderliggende factuur-/contractdossier | 7 jaar vanaf de bewijsgebeurtenis, afgescheiden van securitybewijs en tenantdata. De onderliggende factuur en het contractdossier worden afzonderlijk bewaard vanaf het daarvoor geldende fiscale/contractuele aanvangsmoment |
| Back-ups | afgescheiden korte herstelcyclus; geen regulier gebruik na verwijdering en de verwijderingsinstructie na herstel opnieuw toepassen | maximaal 30 dagen |
| Facturen van de Klant | 7 jaar conform fiscale basisadministratie | minimaal 2555 dagen technisch afgedwongen |
Tenant-specifieke termijnen kunnen door 2LZ op gedocumenteerde instructie worden geconfigureerd. De configuratie wordt in de bestaande tenantconfiguratie opgeslagen. Legal holds moeten specifiek, gedocumenteerd, tijdgebonden en periodiek herbeoordeeld zijn. Aanpassing of opschoning van al bestaande gegevens gebeurt alleen op basis van een gecontroleerde uitvoering en de toepasselijke instructie van de Klant.
De geminimaliseerde beveiligings- en fiscale/contractuele bewijsrecords vallen alleen buiten deze verwerkersovereenkomst voor zover 2LZ daarvoor zelf doel en middelen bepaalt en een afzonderlijke grondslag heeft. De belangenafweging voor beveiligingslogging is vastgelegd in BELANGENAFWEGING-BEVEILIGINGSLOGGING.md. De scheiding is in code en IaC voorbereid maar nog niet gedeployed. De lifecycle van een eventueel bestaand tenantgebonden koud auditarchief en de al aanwezige, onder de oude instelling zeven jaar vergrendelde objecten moeten vóór productie-erkenning live worden geïnventariseerd.
8. Einde dienstverlening
Na één herstel- en exportperiode van maximaal 30 dagen gelden de verwijderafspraken uit artikel 10 van de verwerkersovereenkomst. Een aanvullende productie-bewaartermijn geldt niet. Een wettelijke bewaarplicht van de Klant geeft 2LZ alleen een verdere verwerkingsinstructie wanneer dit vooraf specifiek en schriftelijk is vastgelegd. Back-ups blijven geïsoleerd van regulier gebruik en vervallen binnen hun herstelcyclus van maximaal 30 dagen.
9. Verplichte klantmaatregelen
De Klant:
- verstrekt informatie volgens art. 13/14 AVG;
- beoordeelt en documenteert vóór ingebruikname of een DPIA verplicht is; bij structurele werknemersmonitoring of grootschalige/systematische combinatie van gezondheidsdata met evaluatie of profilering wordt een DPIA uitgevoerd;
- beoordeelt instemmingsrechten van OR/PVT, waaronder art. 27 WOR;
- stelt rollen, toegangsrechten en periodieke controles vast;
- bepaalt bewaartermijnen vóór ingebruikname en geeft 2LZ zo nodig een afwijkende instructie;
- gebruikt het verzuimgesprekssignaal uitsluitend als neutrale gespreksaanleiding en waarborgt dat hieraan geen automatisch of zelfstandig nadelig gevolg wordt verbonden;
- activeert externe integraties pas na beoordeling van ontvanger, rol, contract en doorgifte;
- meldt onjuiste of onrechtmatige instructies direct aan 2LZ.
2LZ informeert de Klant wanneer een instructie naar zijn oordeel in strijd is met de AVG en voert een kennelijk onrechtmatige instructie niet uit zolang Partijen geen rechtmatige oplossing hebben vastgesteld.
Bijlage B — Subverwerkers en externe ontvangers
Bij: Verwerkersovereenkomst 2LZ B.V. (verwerker) ↔ Klant (verwerkingsverantwoordelijke) Versie: 1.6 — 17 juli 2026 Wijzigingen: 2LZ informeert klanten volgens artikel 5.3 van de verwerkersovereenkomst vóór toevoeging of vervanging van een subverwerker.
Deze bijlage onderscheidt:
- subverwerkers die 2LZ zelf inschakelt voor de platformdienst;
- functie-afhankelijke subverwerkers;
- door de Klant gekozen externe ontvangers/integraties, waarbij de juridische rol per koppeling kan verschillen;
- leveranciers die technisch configureerbaar zijn maar niet zonder voorafgaande juridische activering mogen worden gebruikt.
“Beschikbaar in code” betekent niet automatisch “actief voor iedere Klant”. De actuele tenantfunctie en productieconfiguratie bepalen of een gegevensstroom plaatsvindt.
1. Kernsubverwerker
| Partij/juridische entiteit | Dienst | Gegevens | Primaire locatie | Internationale doorgifte / waarborg |
|---|---|---|---|---|
| Amazon Web Services EMEA SARL en relevante AWS-groepsmaatschappijen | ECS/Lambda, DynamoDB, S3, KMS, CloudWatch, SES, SNS/SQS, CloudFront, back-up en beveiliging | afhankelijk van dienst alle platformdata; versleuteld waar beschreven in Bijlage C | primaire workloads eu-west-1 (Ierland) |
AWS DPA; voor support, edge- of groepsverwerking buiten EER: toepasselijke adequaatheid/DPF-certificering of SCC's plus aanvullende maatregelen |
Mollie staat niet in deze kerntabel: de verwerking van abonnement- en betaalgegevens betreft primair de rechtstreekse klantrelatie met 2LZ, waarvoor 2LZ verwerkingsverantwoordelijke is. De gecontroleerde code gebruikt Mollie voor klanten, betalingen, mandaten en abonnementen en gebruikt niet de afzonderlijke dienst Mollie Invoicing. Mollie wordt in de privacyverklaring voor deze rol genoemd. Als Mollie Invoicing later wordt geactiveerd, moeten de verwerkersrol, DPA en deze bijlage vóór activering worden bijgewerkt.
2. Functie-afhankelijke subverwerkers
| Partij | Activering | Gegevens | Doel | Locatie/overdracht | Vereiste contractuele status vóór gebruik |
|---|---|---|---|---|---|
| Expo / EAS (650 Industries, Inc.) | pushnotificaties of EAS-diensten worden gebruikt | Expo-pushtoken, user-ID, berichttitel/-inhoud en contextdata | pushbezorging en mobiele distributiediensten | VS en downstream Apple/Google pushnetwerken | DPA, subprocessoroverzicht en hoofdstuk-V-mechanisme verifiëren; inhoud minimaliseren |
| Google LLC / relevante Google-entiteit | Google login, Calendar/Gmail, Maps/geocoding, Directions/Matrix of FCM-keten wordt geactiveerd | identiteit, e-mail-/agenda-inhoud, OAuth-tokens, adressen, coördinaten of routepunten afhankelijk van functie | gekozen Google-integratie | mogelijk VS/wereldwijd | toepasselijke Google DPA; actuele DPF-certificering per entiteit/dienst of SCC's + doorgiftebeoordeling |
| Microsoft Corporation / relevante Microsoft-entiteit | Microsoft login, Graph, Outlook of Teams wordt gekoppeld | identiteit, e-mail-/agenda-inhoud, deelnemers, OAuth-tokens | gekozen Microsoft-integratie | tenant- en dienstafhankelijk; mogelijk buiten EER | toepasselijke productvoorwaarden/DPA; dataresidency en hoofdstuk-V-mechanisme per tenant verifiëren |
| Apple Inc. / relevante Apple-entiteit | Sign in with Apple of APNs-keten wordt gebruikt | identity-token, eventueel gerelayd e-mailadres, pushmetadata | authenticatie/pushbezorging | mogelijk VS/wereldwijd | toepasselijke voorwaarden/DPA en hoofdstuk-V-mechanisme verifiëren |
| Anthropic PBC | AI-assistent is voor de tenant ingeschakeld en API-configuratie is aanwezig | gebruikersprompt; offerte-, klant-, werkbon- en prijsgegevens afhankelijk van gekozen AI-functie | suggesties, samenvatting, vergelijking en tekstgeneratie | VS | DPA, product-/retentie-instellingen, trainingsuitsluiting, SCC/DPF-status en doorgiftebeoordeling vóór productiegebruik aantoonbaar vastleggen |
| OpenAI, L.L.C. / toepasselijke contractspartij | server-side spraaktranscriptie is via featureflag ingeschakeld en API-configuratie aanwezig | audiobestand, gesproken inhoud, transcript en technische metadata | door gebruiker gevraagde transcriptie | VS/contractafhankelijk | zakelijke DPA, zero-/beperkte retentie waar beschikbaar, trainingsuitsluiting, DPF/SCC en doorgiftebeoordeling vóór productiegebruik vastleggen |
| Postmark / ActiveCampaign, LLC of toepasselijke entiteit | EMAIL_PROVIDER=postmark; standaardcode gebruikt anders AWS SES |
ontvanger, onderwerp, e-mailinhoud en bezorgmetadata | transactionele e-mail | mogelijk VS | DPA, subprocessorregister en hoofdstuk-V-mechanisme vóór activering verifiëren |
| Sentry / Functional Software, Inc. of toepasselijke entiteit | DSN voor backend, admin of mobiel is ingesteld | fout-, performance-, apparaat- en verzoekmetadata; PII wordt waar mogelijk gescrubd | fout- en prestatiemonitoring | mogelijk VS | DPA, regio/retentie, sampling, replay-instellingen, SCC/DPF en PII-filtering vóór activering verifiëren |
3. Overheids- en kaartdiensten
| Partij/dienst | Gegevens | Rol/toelichting |
|---|---|---|
| PDOK Locatieserver | adreszoekvraag of coördinaten | Nederlandse publieke geocodingdienst. De Klant moet voorkomen dat namen of andere niet-noodzakelijke persoonsgegevens in vrije zoektekst worden meegestuurd |
| OSRM (door 2LZ zelf gehost op AWS) | routecoördinaten | De gecontroleerde IaC voorziet in een interne, niet-publieke OSRM-service op AWS Fargate in eu-west-1. OSRM is open-sourcesoftware en geen afzonderlijke ontvanger; AWS is voor deze hosting de subverwerker. De backend kan via een environmentvariabele naar een andere host worden omgeleid. Een externe host mag daarom pas worden gebruikt nadat provider, land, logging, contract en deze bijlage zijn bijgewerkt. |
4. Door de Klant gekozen externe ontvangers en koppelingen
De volgende partijen zijn niet zonder meer subverwerker van 2LZ. Bij een koppeling op verzoek van de Klant kan de partij zelfstandig verwerkingsverantwoordelijke zijn of rechtstreeks verwerker van de Klant. De Klant moet die rol en overeenkomst vóór activering vaststellen.
| Integratie | Mogelijke gegevens | Doel |
|---|---|---|
| AFAS | werknemersreferenties, uren, verlof, salaris-/exportgegevens en connector-token | salaris-/ERP-koppeling |
| Nmbrs | werknemersreferenties, uren, verlof, salaris-/exportgegevens en OAuth-token | salaris-/HR-koppeling |
| Loket.nl | werknemersreferenties, uren, verlof, salaris-/exportgegevens en OAuth-token | salaris-/HR-koppeling |
| 2BA Datapool | bedrijfs-/accountgegevens, product-, prijs-, voorraad- en zoekgegevens | product- en calculatiekoppeling; persoonsgegevens moeten worden geminimaliseerd |
| Door de Klant ingestelde webhook/API-partner | gegevens die binnen de gekozen scope worden verzonden | klantgestuurde integratie; de Klant sluit waar nodig zelf een verwerkersovereenkomst en beheert scopes/sleutels |
2LZ moet in de gebruikersinterface duidelijk maken wanneer gegevens de 2LZ-omgeving verlaten en welke partij de ontvanger is.
5. Niet geautoriseerd zonder voorafgaande update
- n8n: in documentatie eerder genoemd voor toekomstige importautomatisering, maar in de huidige privacy-inventaris niet als rechtmatig geactiveerde subverwerker aangetoond. Geen persoonsgegevens via n8n verwerken voordat contract, locatie, beveiliging, doorgifte en dit register zijn bijgewerkt.
- SendGrid of andere e-mailprovider: een configuratie-/testmogelijkheid geldt niet als juridische activering. Eerst dit register en de relevante privacyinformatie aanpassen.
- iedere nieuwe analytics-, marketing-, AI-, support- of hostingprovider.
6. Doorgifte buiten de EER
Voor elke concrete derde-landstroom legt 2LZ vast:
- exporteur, importeur en juridische entiteiten;
- categorieën gegevens, betrokkenen, doel en frequentie;
- adequaatheidsbesluit of toepasselijke SCC-module;
- actuele DPF-certificering wanneer daarop wordt vertrouwd;
- doorgiftebeoordeling en aanvullende technische/organisatorische maatregelen;
- retentie, verwijdering en eventuele training/hergebruik door de leverancier;
- downstream subverwerkers en locaties.
Een algemene verwijzing naar “VS — adequaatheidsbesluit” of alleen naar een leveranciers-DPA is onvoldoende. Bewijsstukken worden opgenomen in het interne leveranciersdossier en op verzoek in passende vorm aan de Klant beschikbaar gesteld.
7. Operationele verificatieplicht
De aanwezigheid van deze tabel bewijst niet dat alle vereiste DPA's, SCC's of certificeringen daadwerkelijk zijn ondertekend of actueel zijn. De eigenaar van het privacyprogramma verifieert dit minimaal jaarlijks en vóór iedere activering. Niet-geverifieerde functie-afhankelijke leveranciers blijven uitgeschakeld voor persoonsgegevens.
Bijlage C — Technische en organisatorische maatregelen (AVG art. 32)
Bij: Verwerkersovereenkomst 2LZ B.V. (verwerker) ↔ Klant (verwerkingsverantwoordelijke). Versie: 1.6 — 17 juli 2026. Doel: beschrijft de beveiligingsmaatregelen die 2LZ als verwerker treft conform art. 32 AVG. Peildatum documentcontrole: 2026-07-17. Onderhoud: dit document wordt bijgewerkt bij materiële wijzigingen. Status van dit document: afgestemd op de beschikbare code- en infrastructuurconfiguratie. Dit document is geen onafhankelijke certificering of garantie dat iedere maatregel in iedere omgeving actief is. Waar activering of productieherverificatie nodig is, wordt dat expliciet vermeld.
1. Versleuteling (art. 32 lid 1 sub a)
1.1 Versleuteling in transport
- Alle verkeer via TLS 1.2+ (HTTPS). HTTP wordt 301-geredirect naar HTTPS (ALB + CloudFront).
- HSTS
max-age=31536000; includeSubDomains; preloadin productie. - Auth-cookies:
httpOnly,secure,SameSite=strict(regulier) /lax(OAuth-callbacks).
1.2 Versleuteling at-rest — infrastructuur
- DynamoDB: server-side encryptie (SSE) met door de klant beheerde KMS-sleutel (
alias/2lz-production-dynamodb), op alle tabellen. - S3: SSE-KMS op alle buckets met persoonsgegevens (uploads, audit-archief, backups); statische website-assets AES256.
- Secrets (JWT-, cookie-, sessie-, encryptiesleutels): AWS Secrets Manager, versleuteld met KMS.
1.3 Versleuteling at-rest — applicatielaag (veld-niveau PII)
- Mechanisme: KMS-envelope-encryptie, AES-256-GCM, per veld (
encryption.service.ts,pii-encryption.helper.ts). - Sleutelmodel (live geverifieerd): één PII-CMK
alias/2lz-production-pii(master-key-model;KMS_PER_TENANT_KEYS=false). De code ondersteunt per-tenant-sleutels als toekomstige optie; die staan in productie niet aan. - De applicatie stuurt geen KMS EncryptionContext; de key-policy is hierop afgestemd (geen context-conditie). (Correctie t.o.v. de niet-gedeployde
kms.yaml-template, die wél een per-tenant/context-variant beschrijft maar niet in productie draait.) - Versleutelde velden per entiteit (werkelijk toegepast in de repositories):
- USER:
phone,birthDate,employeeNumber,mfaSecret,iban - SICK_LEAVE legacy: historische
phoneNumber,hrNotes,managerNotesen contactvelden blijven door de repository versleuteld zolang zij nog gecontroleerd worden bewaard; de actieve API/UI retourneert deze velden niet en nieuwe meldingen vullen ze niet - EMAIL_ACCOUNT / CALENDAR_ACCOUNT (OAuth):
accessToken,refreshToken,providerEmail,signatureHtml
- USER:
- Dual-read (
isEncryptedValue): plaintext en versleutelde waarden kunnen naast elkaar bestaan — veilige uitrol/rollback zonder leesbreuk. - Statusmarkering: de applicatielaag-PII-encryptie is infra-volledig voorbereid (CMK + sleuteltoegang live); de activerende schakelaar
ENCRYPTION_ENABLEDwordt gecontroleerd geactiveerd met aansluitende backfill van bestaande records. (Dit document wordt bij activering bijgewerkt naar "actief".) - KMS-sleutels: jaarlijkse automatische rotatie ingeschakeld op de symmetrische sleutels; JWT-signing-sleutel (RSA-2048) handmatige rotatie.
2. Vertrouwelijkheid en toegangscontrole (art. 32 lid 1 sub b)
2.1 Multi-tenant isolatie
- Fysieke datasegmentatie via partition keys:
PK = TENANT#<tenantId>. Elke repository erftBaseRepository, die op elke operatie tenant-validatie en ownership-controle afdwingt; cross-tenant-toegang wordt geblokkeerd en als security-event gelogd. - Tenant-identiteit komt uitsluitend uit de geverifieerde JWT-claim — nooit uit query/body/path. Spoofing-pogingen → 403 + kritiek security-event.
2.2 Authenticatie
- Wachtwoorden: bcrypt, 12 rounds. Wachtwoordsterkte-eisen voor onboarding (min. 12, hoofd/klein/cijfer/speciaal).
- MFA (TOTP) beschikbaar;
mfaSecretversleuteld opgeslagen; enrollment/verificatie audit-gelogd. - JWT: access-token 15 min, refresh-token met rotatie + family-tracking (hergebruik-detectie/revocatie).
- Single-session enforcement per gebruiker/platform (session-registry).
2.3 Autorisatie
- RBAC, 4 niveaus (super_admin > admin/owner > office/hr/planner > monteur/viewer/employee) + scope-permissies. Middleware-volgorde:
authenticate → tenantSecurity → requireRole → validate. - Ziekmeldingendossiers gebruiken aanvullend een exacte rollenlijst (
super_admin,admin,owner,office,hr);planneren overige rollen krijgen geen dossier- of gesprekssignaaltoegang. Planning ontvangt uitsluitend de noodzakelijke beschikbaarheidsimpact. - Super-admin-impersonatie uitsluitend voor super_admin, gescoped op de doel-tenant, met
IMPERSONATION_START/ENDaudit-events. - API-sleutels: alleen de SHA-256-hash wordt opgeslagen; per tenant; rotatie/intrekking audit-gelogd.
3. Logging, detectie en audit (art. 32 + accountability)
- Tenantgebonden audit-trail (
audit-trail.service.ts): DynamoDB conditional writes voor integriteit en querybaarheid. Gewone gebruikers- en activiteitengebeurtenissen blijven tenantgebonden, gaan niet naar een Object Lock-bucket en vallen onder de tenantretentie en exitverwijdering. - Minimaal beveiligingsbewijs: alleen expliciete authenticatie-, autorisatie-, security-, impersonatie-, geselecteerde rechtenuitoefenings- en account-/integratiebeveiligingsgebeurtenissen worden aanvullend naar CloudWatch en de bestaande audit-trailbucket geschreven. Algemene toestemmings- en gebruikersactiviteit valt daar niet onder. Tenant-, actor- en resourcereferenties worden met SHA-256 gepseudonimiseerd. De bewijsrecord bevat geen naam, e-mail, user-agent, locatie, details, wijzigingenpayload of fouttekst. Een aanwezig IP-adres blijft maximaal 365 dagen beschikbaar voor incidentonderzoek.
- Minimaal fiscaal/contractueel bewijs: klantfactuur- en contractgebeurtenissen gaan naar een nieuwe, afzonderlijke S3 Object Lock-bucket met zeven jaar retentie. IP-adres en businesspayload worden daar niet opgenomen.
- CloudWatch-retentie: de service stelt op het securitylogboek maximaal 365 dagen in en schrijft gewone tenantactiviteit niet naar dat logboek.
- PII-redactie in overige logs: wachtwoorden/tokens/secrets/MFA/OTP worden vóór wegschrijven gemaskeerd (
log-redaction.js). - Open productie- en legacyafwijking: deze scheiding is in code en IaC voorbereid maar nog niet gedeployed. Bestaande objecten die onder de oude algemene zevenjaarsinstelling zijn geschreven behouden hun al vastgelegde retentiedatum. De live CloudWatch-retentie, beide evidencebuckets en de lifecycle van een eventueel tenantgebonden koud auditarchief moeten vóór contractuele productie-erkenning in staging en productie worden bewezen. De verwerkersovereenkomst blijft tot die verificatie fail-closed geblokkeerd.
- Security-alerting: drempelgebaseerde alerts (mislukte logins, account-lockout, token-hergebruik, MFA-uitschakeling, encryptie-fouten) → e-mail/in-app/push, met rate-limiting.
4. Beschikbaarheid en herstelbaarheid (art. 32 lid 1 sub c)
- DynamoDB Point-in-Time Recovery (PITR) in de infrastructuurconfiguratie op alle relevante tabellen met een herstelvenster van maximaal 30 dagen. De live instelling moet vóór productie-erkenning per tabel worden geverifieerd.
- S3 versioning + lifecycle; afzonderlijke Object Lock-retentie van 365 dagen voor minimaal beveiligingsbewijs en zeven jaar voor minimaal fiscaal/contractueel bewijs.
- TTL voor automatische opschoning (sessies, retentie).
- DR-herstelprocedure (
dr-drill-rol + runbook) — periodieke hersteloefening; RTO/RPO-meting op de roadmap. - Een herstel mag verwijderde tenantgegevens niet opnieuw in regulier gebruik brengen; de vastgelegde verwijderingsinstructie wordt na herstel opnieuw uitgevoerd.
5. Netwerk- en applicatiehardening
- ECS Fargate in private subnets; geen directe internettoegang tot de backend; egress via NAT.
- AWS WAF op de ALB: OWASP-, bad-inputs-, SQLi-, OS-command- en IP-reputatie-regelsets + rate-limiting.
- Rate limiting per endpointtype (login 10/min, API 300/min, upload 10/uur, etc.), Redis-backed met memory-fallback.
- Input-validatie: express-validator (HTTP) + Zod (business); body-sanitization.
- Veilige uploads: MIME-whitelist + magic-bytes-verificatie + groottelimiet + bestandsnaam-sanering + gevaarlijke-extensie-blocklist; verdachte bestanden naar quarantaine-bucket (virusscan-Lambda).
- Helmet + strikte CSP,
X-Frame-Options: DENY,nosniff, restrictievePermissions-Policy; CSRF-bescherming (timing-safe, 256-bit token).
6. Bijstand aan de verwerkingsverantwoordelijke (art. 28 lid 3 sub e/f)
2LZ levert tooling waarmee de klant zijn AVG-verplichtingen kan nakomen:
- Inzage/portabiliteit (art. 15/20): data-export per gebruiker (JSON), tijdelijk beschikbaar, met
no-store-headers. - Vergetelheid/rectificatie (art. 16/17): anonimiseringsfunctie (PII verduisteren met behoud van wettelijk verplichte administratie); legal holds om verwijdering te pauzeren bij bewaarplicht/geschil.
- Bewaartermijnen centraal beheerd (
data-retention.service.ts) — zie Bijlage A. - Registratie van een actieve locatiebevestiging (
requireLocationConsent) vóór GPS-tracking. Dit is een technische controle- en transparantiemaatregel en bewijst niet zelfstandig dat toestemming in een arbeidsrelatie vrij is gegeven of dat een andere grondslag geldig is.
7. Subverwerkers en doorgifte
Zie Bijlage B (subverwerkers en externe ontvangers). Primaire opslag staat in AWS eu-west-1 (Ierland). Functie-afhankelijke verwerking kan plaatsvinden via onder meer Expo, Google, Microsoft, Apple, Anthropic, OpenAI, Postmark of Sentry. Activering vereist voorafgaande verificatie van rol, DPA, locatie, retentie en het toepasselijke hoofdstuk-V-mechanisme. Providerconfiguratie en uitgaande datastromen worden periodiek geïnventariseerd.
8. Organisatorische maatregelen
- Toegang tot productie via MFA + tijdelijke, geauditeerde sessies; geen gedeelde rootsleutels in dagelijks gebruik.
- Wijzigingen via CI/CD met verplichte groene security-/test-gates vóór productie-deploy.
- Geheimen uitsluitend via Secrets Manager; nooit in code of logs.
Dit dossier ondersteunt de verantwoordingsplicht van art. 5 lid 2 en art. 32 AVG en is bijlage bij de verwerkersovereenkomst. Voor contractuele verstrekking wordt de actuele productieconfiguratie gecontroleerd en worden afwijkingen of nog niet geactiveerde maatregelen expliciet vermeld.