Verwerkersovereenkomst

1. Wie verwerker is en wie verantwoordelijke

Wat de software vastlegt: een klant van Bandhub (de accounthouder) bepaalt zelf welke persoonsgegevens van zijn muzikanten en contactpersonen hij in zijn account invoert; Bandhub bewaart en verwerkt die gegevens namens hem, zonder daar zelf een eigen doel mee na te streven. De klant is dus verwerkingsverantwoordelijke, de eigenaar van Bandhub is verwerker.

Vraag: naam, adres en KvK-nummer van de verwerker, voor in de overeenkomst zelf.

2. Welke gegevens en van wie

Wat de software vastlegt: elke klant heeft een eigen klantbestand met daarin (sql/schema_tenant.sql):

contacts (contactpersonen bij podia) — voornaam, achternaam, functie, twee e-mailadressen, telefoon, adres, postcode, plaats, land, website, Facebook, Instagram, notities.

musicians (muzikanten) — voornaam, achternaam, e-mailadres, telefoon, instrument, pasfoto, website, Facebook, Instagram, een korte biografie, notities, en — voor wie een eigen discografiepagina koppelt — de inloggegevens van diens eigen WordPress-site (gebruikersnaam en wachtwoord van een "application password").

Daarnaast: bookings/booking_lineup (welke muzikant bij welk optreden hoort en welke gage hij daarvoor krijgt), en portal_views/interaction_log (wie een publieke link — bijvoorbeeld een beschikbaarheidsvraag — heeft geopend en wanneer). Voor zover in het schema te zien, staan er geen bijzondere persoonsgegevens (gezondheid, ras, geloof) in.

Vraag: is deze lijst compleet genoeg voor de overeenkomst, en moet het WordPress-wachtwoord van de klant zelf (niet van diens muzikant, maar wél een inloggeheim dat Bandhub namens de klant bewaart) apart worden benoemd als extra gevoelig?

3. Wat de verwerker ermee mag

Vraag: uitsluitend verwerken in opdracht van de verantwoordelijke, voor het doel van de dienst zelf, en niet voor eigen doeleinden — de gebruikelijke bepaling, hier nog te formaliseren.

4. Welke beveiligingsmaatregelen er zijn

Wat de software vastlegt: elk klantbestand (SQLite) heeft een onvoorspelbare naam — tenant_path() in tenant.php accepteert uitsluitend namen die voldoen aan het patroon klant_<id>_<16 hexadecimale tekens>.sqlite, en is de enige plek waar een pad naar een klantbestand ontstaat. De functie in db.php die de databaseverbinding van de ingelogde klant opent, leest per verzoek precies het ene bestand van die klant; er is geen query in de applicatie die over meerdere klantbestanden heen gaat. De klantbestanden staan buiten de webmap (de map naast de webmap, zie config.php), zodat de webserver ze nooit rechtstreeks kan uitleveren — index.php weigert zelfs te starten als dat niet zo is.

Geüploade bestanden (contracten, persfoto's, bandbestanden) krijgen eveneens een willekeurige bestandsnaam (bin2hex(random_bytes(...)) in actions.php) en staan ook buiten de webmap; ze gaan de deur alleen uit via een downloadroute die de toegang controleert, nooit via een directe URL. Wachtwoorden van accounthouders worden gehasht opgeslagen (kolom wachtwoord_hash in de tabel logins), niet in leesbare vorm.

Vraag: is dit voldoende voor de beveiligingsparagraaf van de overeenkomst, of moet er ook iets komen over versleuteling van de reservekopieën, wie er (bijvoorbeeld bij onderhoud) toegang heeft tot de server, en toegangslogging voor de eigenaar zelf?

5. Subverwerkers

Wat de software vastlegt: voor e-mail gebruikt Bandhub een eigen postbus op het eigen domein (functions.php, send_email(), SMTP via mail.bandhub.nl) — geen extern verzenddienst-account. De hostingpartij (NameHero) is in praktische zin wel een subverwerker: de gegevens staan fysiek op hun infrastructuur.

Wat er géén subverwerker is: Google. De lettertypen werden tot 3 september 2026 bij fonts.googleapis.com opgehaald, waardoor het IP-adres van elke muzikant die een uitvraag opende bij Google terechtkwam. Ze staan nu op onze eigen server, dus die verwerking bestaat niet meer en Google hoeft hier niet genoemd te worden.

Vraag: moet NameHero hier als subverwerker worden genoemd, en is er een verwerkersovereenkomst met NameHero zelf? En: komen Stripe en PayPal (de beoogde betaaldiensten, nog niet aangesloten) hier straks bij? Zij zien de gegevens van de bandleider die het abonnement afsluit; of ze ook gegevens van diens muzikanten te zien krijgen hangt af van hoe het afrekenen wordt ingericht.

6. Wat er gebeurt bij een datalek en binnen welke termijn

Vraag: binnen welke termijn meldt de verwerker een (vermoeden van een) datalek aan de verantwoordelijke, en op welke manier? Er is geen geautomatiseerde detectie- of meldprocedure in de code; dit moet procedureel worden vastgelegd, niet technisch afgeleid.

7. Hoe de verantwoordelijke zijn eigen betrokkenen kan bedienen

Wat de software vastlegt: een muzikant of contactpersoon kan zelf, zonder eigen account, reageren via een publieke link met een token (tabel publieke_tokens, sql/schema_admin.sql, en band_portals / booking_portals in sql/schema_tenant.sql) — bijvoorbeeld om op een beschikbaarheidsvraag te antwoorden. De klant zelf kan de gegevens van zijn muzikanten en contactpersonen in zijn account inzien, wijzigen en verwijderen. Er is geen aparte exportknop voor de gegevens van één losse betrokkene aangetroffen, los van wat de klant handmatig uit zijn overzichten kan halen.

Vraag: is dat voldoende om de verantwoordelijke in staat te stellen een AVG-verzoek van zijn eigen betrokkene (bijvoorbeeld een muzikant die inzage vraagt) af te handelen, of moet daar een specifieke exportfunctie voor komen?

8. Wat er met de gegevens gebeurt bij beëindiging

Wat er is vastgelegd (nog niet gebouwd): Bandhub-ontwerp.md §9.6 beschrijft het voornemen: bij opzegging krijgt de klant een export van zijn gegevens, het account blijft daarna een afgesproken termijn bewaard voor spijtoptanten, en wordt dan definitief verwijderd — bestand en al. Technisch is dat eenvoudig: tenant_path() wijst naar precies één bestand per klant, er is geen gedeelde tabel die daarbij schoongemaakt moet worden. De bewaartermijn zelf staat in Bandhub-ontwerp.md §13 nog als open punt. Reservekopieën van vóór de verwijdering blijven vermoedelijk nog een tijd bestaan in de reservekopiemap naast de webmap — daarvoor is in de code geen automatische opschoning gevonden (zie ook kopje 4 hierboven, en de privacyverklaring, kopje 4).

Vraag: wat is de bewaartermijn na beëindiging, en worden de reservekopieën na die termijn actief opgeruimd, of lopen ze vanzelf uit de bewaarcyclus van de reservekopieën zelf?

9. Audit

Vraag: heeft de verantwoordelijke het recht een audit te (laten) uitvoeren, hoe vaak, en wie draagt de kosten? Zuiver juridisch, geen technische basis in de code.