Data van mijn gasten beveiligen?

[galaumiy]

Hallo,

Ik zit met het volgende. Ik ben sinds kort met de overname van een restaurant door een vriend verantwoordelijk voor de technische infra.

Hierin komen bijvoorbeeld de wifi, tv narrowcasting, geluidsinstallatie, discoverlichting, kassasysteem, publiekelijk website, etc. etc. bij komen kijken. Daarnaast hebben wij een reserveringssysteem die meer dan alleen een naam in de database bewaart. Kort gezegd, heel veel privacygevoelige data, maar voor intern gebruik alleen.

Tot vandaag mochten de gasten alleen telefonisch een reservering vastleggen, maar daar willen wij een verandering in brengen. De reserveringssysteem moet een koppeling krijgen met een WordPress website, die dan enkel door ingelogde gebruikers een reservering mogen plaatsen. Deze online aanvraag komt bij ons in het systeem terecht voor goedkeuring. Na goedkeuring wordt dan de profiel van deze gebruikers geupdatet.

Heel leuk, maar ik maak me toch zorgen om de privacygevoelige informatie van alle gasten die wij bewaren. Ik weet niet hoe veilig WordPress en de (gravity forms) plugin hiervoor is, verder geen idee hoe veilig de gemaakte koppeling straks wordt. Ik mag dan wel alles over SSL gaan doen, maar als de website gehacked wordt dan is ook alle informatie alsnog opvraagbaar.

Hebben jullie wat tips voor mij? Hoe kan ik mezelf hiertegen goed beveiligen? In worst case, hoe kan ik de opgevraagde informatie beperken tot alleen een naam, e-mailadres of random klantnummers?
Hoe zouden jullie dit realiseren?

Alvast bedankt.

[AceAceAce]

Outsourcen via een toko zoals thefork?

[mcDavid]

Er is niet "een ding" wat je kunt doen om je beveiliging te fixxen. Je hele applicatie moet gewoon veilig zijn, en op alle niveaus de best practices volgen. Als je geen idee hebt wat je daarvoor allemaal moet doen, zou ik je idd aanbevelen het project uit te besteden aan iemand/een organisatie die dat wel heeft.

Wil je zekerheid, dan zou je een security audit uit moeten laten voeren. Hoewel dat wellicht te ver gaat voor een dergelijke onderneming.

[Icephase]

Waarom zou je méér dan alleen de naam en een mailadres of telefoonnummer van je gast willen vastleggen eigenlijk? Dataveiligheid begint al met nadenken over welke data je verzamelt/verwerkt.

Daarna komt de wet op de privacy/AVG om de hoek kijken. Je moet dus expliciete toestemming hebben van je klanten om hun gegevens te verwerken (vastleggen = verwerken) plus je moet kunnen uitleggen waarom je dat nodig hebt. Je moet klanten inzicht geven in hun data en je moet het verwijderen op verzoek.

Tot slot ga je nadenken over beveiliging. Of het nou intern gebruikt wordt of gedeeld wordt, je moet je data afschermen van ongeautoriseerden - hetzij de eigen medewerkers of hackers van buitenaf.

[Verwijderd]

Opzich zijn implementaties als Wordpress prima toepasbaar in dit soort scenario's maar dan moet je die wel een beetje basic houden zodat die ook heel makkelijk bij te werken is.
Wordpress heeft nogal eens een gaatje, hoge bomen enzo, dus updaten is wel een must.

Ik zie nog wel eens wordpress installaties waar zo'n handig mannetje naar heeft gekeken maar daar is dan van alles aan verbouwd en weet je eigenlijk niet meer wat er gebeurd als je dat ding update.
Dat moet je m.i. zo veel mogelijk ontwijken.

Verder wil ik los hiervan idd adviseren om te kijken naar The Fork zoals door @AceAceAce gesuggereerd. Ik gebruik dat doorlopend om restaurants te zoeken en te reserveren. Ik weet niet hoe snel ik me door hoepels zou laten drukken op een website.

[ Voor 50% gewijzigd door Verwijderd op 19-08-2019 14:07 ]

[bonzz.netninja]

Heel leuk, maar ik maak me toch zorgen om de privacygevoelige informatie van alle gasten die wij bewaren. Ik weet niet hoe veilig WordPress en de (gravity forms) plugin hiervoor is, verder geen idee hoe veilig de gemaakte koppeling straks wordt. Ik mag dan wel alles over SSL gaan doen, maar als de website gehacked wordt dan is ook alle informatie alsnog opvraagbaar.

Dat is wel zo, maar op zich is jouw plicht wel genuanceerd in de wetgeving dan je wellicht denkt. Als jij gegevens gaat verwerken dan moet je passende beveiligingsmaatregelen treffen. Of het passend is ligt uiteraard aan de aard van de gegevens, en naam en telefoon is van andere aard dan biometrische gegevens Tevens, als je ervoor zorgt dat je de gegevens direct ook weer verwijderd scheelt dat ook weer een hoop.

Ja je moet er goed voor zorgen, maar als jij gewoon netjes wordpress up to date houd, bijhoud wat je verwerkt en waarom (en of je dat mag dmv toestemming (die je wel moet loggen)) dan ben je een heel eind. De aard van je verwerking en de aard van je gegevens zou naar mijn idee niet veel verdere maatregelen eisen. Ja je kan gehackt worden want dat kan altijd, en dan ligt de boel op straat, maar je hebt voldaan aan je plicht en als je netjes een datalek meld, is er niet zo veel aan de hand.

[WeHoDo]

Zou een formulier maken en deze dan een xml laten sturen naar een mail adres die een ander systeem kan inlezen.Of het reserveringssysteem de xml laten ophalen en na het inlezen verwijderen op de site..

De website extern, reservering systeem intern.

Zo doe ik het al jaren voor een kapperszaak.

[mcDavid]

Icephase schreef op maandag 19 augustus 2019 @ 14:00:
Waarom zou je méér dan alleen de naam en een mailadres of telefoonnummer van je gast willen vastleggen eigenlijk? Dataveiligheid begint al met nadenken over welke data je verzamelt/verwerkt.

Pfft, ik kan nogal wat verzinnen? Om te beginnen aankomst- en vertrekdata. Is al een leuke. Verder natuurlijk allerlei andere opties die je verkoopt, bijzondere wensen van de klant, etc.

Daarna komt de wet op de privacy/AVG om de hoek kijken. Je moet dus expliciete toestemming hebben van je klanten om hun gegevens te verwerken (vastleggen = verwerken) plus je moet kunnen uitleggen waarom je dat nodig hebt. Je moet klanten inzicht geven in hun data en je moet het verwijderen op verzoek.

Dat hoeft helemaal niet. Data die nodig is voor de levering van je product en/of dienst, mag je altijd verwerken. Voor het stukje inzicht en verwijderen, hoef je eigenlijk niets te ontwerpen. Ditsoort verzoeken kun je prima handmatig verwerken, zolang het er niet om tientallen per dag gaat.

[Icephase]

mcDavid schreef op maandag 19 augustus 2019 @ 14:17:
[...]
Pfft, ik kan nogal wat verzinnen? Om te beginnen aankomst- en vertrekdata. Is al een leuke. Verder natuurlijk allerlei andere opties die je verkoopt, bijzondere wensen van de klant, etc.

[...]

Dat hoeft helemaal niet. Data die nodig is voor de levering van je product en/of dienst, mag je altijd verwerken. Voor het stukje inzicht en verwijderen, hoef je eigenlijk niets te ontwerpen. Ditsoort verzoeken kun je prima handmatig verwerken, zolang het er niet om tientallen per dag gaat.

Het gaat om een restaurant... en data/tijden zijn geen persoonsgegevens.
Welke 'andere opties' bedoel je trouwens? En data die nodig is voor het leveren van een tafeltje met voedsel en drinken? Kijk dat je een naam en telefoonnummer nodig hebt zodat je weet wie je kunt verwachten is logisch maar meer dan dat? Ik snap dat het vanuit een commercieel oogpunt wenselijk is om een soort CRM-systeem te onderhouden maar die data is echt niet noodzakelijk voor het leveren van de dienst of het product hoor.

[sypie]

Even vanuit mijn oogpunt als "consument".

Ik zou het juist helemaal niet prettig vinden om een account aan te moeten maken om een reservering te moeten maken voor een hapje eten. De eerste gedachte die bij mij opkomt: "alweer een account".

Uiteraard moet er een manier zijn waarmee je de reservering kunt bevestigen, zodat er niet door iedereen gereserveerd wordt en er uiteindelijk niemand komt. Daar moet je over nadenken bij dergelijke systemen, dat is begrijpelijk.

Verder zou het mooi zijn, zeker gezien de AVG, hacks en weet ik wat er nog meer mogelijk is, dat data niet langer bewaard wordt dan laten we zeggen een maand of 2. Het is voor weinig mensen interessant om te laten zien dat ik 5 jaar geleden bij jou ben wezen eten. Data die je niet (meer) hebt kan ook niet gestolen worden.

[galaumiy]

Goedemiddag,

Het gaat om een restaurant met zittend live muziek en waar veel sterke alcohol genuttigd wordt. Wij dienen het gedrag van de gasten heel goed in de gaten te houden.

Wij bewaren de volgende gegevens:
prive: Voornaam, achternaam, emailadres, telefoonnummer, postcode, huisnummer, land.
reserveringonderdeel: dag en tijd reservering, werkelijke aankomsttijd/vertrektijd, gedrag klant, totale betaling, lidmaatschapskaart wel/niet, toepassen korting op basis van aantal reserveringen/totale betaling.

Door de info die wij hebben is outsourcen geen optie. Verder denk ik ook niet dat de applicatie het probleem is, maar wel de koppeling vanuit de website naar de applicatie.

Dit ding is straks mooi om in MS PowerBI te zien, daar ben ik dan niet bang voor.

Verder ben ik enorm bewust van het AVG-verhaal. Ik weet dat ik al mijn data veilig moet stellen en liefst zoveel mogelijk "offline" bewaar. Maar naast het AVG-verhaal speelt imago ook een rol. Niemand wilt dat deze informatie op straat komt (bruikbaar of niet).

Niemand staat te wachten op een "account" op een website, maar de verplichting is er omdat wij te maken hebben met vele valse reserveringen van onze directe concurrenten. Uiteraard is bellen veel sneller dan de website. Maar als deze een paar reserveringen kan afhandelen dan is het voor de collega die de telefoon aanneemt iets rustgevend.

Als 10-20% via de website gedekt wordt is al voldoende.

[Killjoy]

Even wat vragen/opmerkingen:

galaumiy schreef op maandag 19 augustus 2019 @ 15:19:
Goedemiddag,

Het gaat om een restaurant met zittend live muziek en waar veel sterke alcohol genuttigd wordt. Wij dienen het gedrag van de gasten heel goed in de gaten te houden.

Is dit een een wettelijke verplichting? Of is dit op eigen initiatief?

Wij bewaren de volgende gegevens:
prive: Voornaam, achternaam, emailadres, telefoonnummer, postcode, huisnummer, land.
reserveringonderdeel: dag en tijd reservering, werkelijke aankomsttijd/vertrektijd, gedrag klant, totale betaling, lidmaatschapskaart wel/niet, toepassen korting op basis van aantal reserveringen/totale betaling.

Als gebruikers in moeten loggen, dan bewaar je meer. Namelijk gebruikersnaam en wachtwoord (of hash ervan), informatie in logfiles, zoals (mogelijk) IP-adres, tijdstip en frequentie van bezoeken, zoekgedrag op de website, enz.

Doe je ook een leeftijdscheck bij aanmaak profiel op de site?

Door de info die wij hebben is outsourcen geen optie.

Waarom niet dan?

Verder denk ik ook niet dat de applicatie het probleem is, maar wel de koppeling vanuit de website naar de applicatie.

Dat is maar de vraag. Is het een applicatie die lokaal draait? Of is het een cloudtoepassing? Wie hebben toegang tot de server? Hoe is de beveiliging geregeld?

Dit ding is straks mooi om in MS PowerBI te zien, daar ben ik dan niet bang voor.

Verder ben ik enorm bewust van het AVG-verhaal. Ik weet dat ik al mijn data veilig moet stellen en liefst zoveel mogelijk "offline" bewaar. Maar naast het AVG-verhaal speelt imago ook een rol. Niemand wilt dat deze informatie op straat komt (bruikbaar of niet).

Maar wat ik dan mis is een uitleg over hoe je het dan technisch op wil zetten. Hoe wordt straks ingelogd. Pas je multifactor authenticatie toe? Pas je dataminimalisatie toe?

Hoe ontsluit je data van de 'offline' applicatie naar de website; geef je na inlog in de beveiligde omgeving ook toegang tot alle eerder genoemde persoonsgegevens om op die manier invulling te geven aan het recht op inzage van de AVG? Of is het éénrichtingverkeer waarbij er alleen gegevens worden geschreven naar de back-end.

Niemand staat te wachten op een "account" op een website, maar de verplichting is er omdat wij te maken hebben met vele valse reserveringen van onze directe concurrenten. Uiteraard is bellen veel sneller dan de website. Maar als deze een paar reserveringen kan afhandelen dan is het voor de collega die de telefoon aanneemt iets rustgevend.

Als 10-20% via de website gedekt wordt is al voldoende.

Als directe concurrenten een bedreiging zijn, kunnen ze je ook zieken door valse profielen aan te maken. Welke waarborgen heb je getroffen om dit te voorkomen? Kan iemand via de website een account aanmaken? Of kan dat alleen met tussenkomst van een beheerder? En hoe doe je de verificatie?

[Jeroenneman]

galaumiy schreef op maandag 19 augustus 2019 @ 15:19:
Goedemiddag,

Het gaat om een restaurant met zittend live muziek en waar veel sterke alcohol genuttigd wordt. Wij dienen het gedrag van de gasten heel goed in de gaten te houden.

Wij bewaren de volgende gegevens:
prive: Voornaam, achternaam, emailadres, telefoonnummer, postcode, huisnummer, land.
reserveringonderdeel: dag en tijd reservering, werkelijke aankomsttijd/vertrektijd, gedrag klant, totale betaling, lidmaatschapskaart wel/niet, toepassen korting op basis van aantal reserveringen/totale betaling.

Door de info die wij hebben is outsourcen geen optie. Verder denk ik ook niet dat de applicatie het probleem is, maar wel de koppeling vanuit de website naar de applicatie.

Dit ding is straks mooi om in MS PowerBI te zien, daar ben ik dan niet bang voor.

Verder ben ik enorm bewust van het AVG-verhaal. Ik weet dat ik al mijn data veilig moet stellen en liefst zoveel mogelijk "offline" bewaar. Maar naast het AVG-verhaal speelt imago ook een rol. Niemand wilt dat deze informatie op straat komt (bruikbaar of niet).

Niemand staat te wachten op een "account" op een website, maar de verplichting is er omdat wij te maken hebben met vele valse reserveringen van onze directe concurrenten. Uiteraard is bellen veel sneller dan de website. Maar als deze een paar reserveringen kan afhandelen dan is het voor de collega die de telefoon aanneemt iets rustgevend.

Als 10-20% via de website gedekt wordt is al voldoende.

Klinkt niet als een normaal restaurant. Waarom wil je in godsnaam een postcode en huisnummer vastleggen en wat vul je in bij "gedrag klant"?

En natuurlijk kunnen je concurrenten gewoon valse huisnummers invullen, dat is niet zo moeilijk. Net zoals het ook een koud kunstje is om een paar fake accounts aan te maken.

[sypie]

Het adres van de klant is helemaal niet interessant. Behalve wanneer het zo'n tent is waar geregeld de pleuris uitbreekt, dan is het handig dat je politie naar het juiste adres kunt sturen. Verder heeft een restaurant daar niks mee te maken.

Er bestaat ook zoiets als "teveel informatie willen hebben". Net als de grote bedrijven dat doen.

Ooit een keer bij een kapper geweest die wilde mij ook in z'n agenda zetten. Ik was daar al in de zaak om een afspraak te maken. Voor dit systeem hadden ze ook allerlei NAW gegevens nodig. Waarop mijn reactie was dat ik alleen maar geknipt hoefde te worden. Vervolgens kwam er een of ander excuus van hun kant om toch deze gegevens in te voeren. Waarop ik mijn excuses heb aangeboden, mij heb omgedraaid en het pand verlaten heb.

Ditzelfde zou ik voor een restaurant ook doen. Ook al zouden Jonnie en Thérèse Boer er naar vragen bij een reservering.

Voornaam, achternaam, telefoonnummer en mailadres. Meer hoef je niet en meer heb je niet nodig.

[Jester-NL]

galaumiy schreef op maandag 19 augustus 2019 @ 15:19:
Goedemiddag,

Het gaat om een restaurant met zittend live muziek en waar veel sterke alcohol genuttigd wordt. Wij dienen het gedrag van de gasten heel goed in de gaten te houden.

Ik lees hier niet "restaurant" maar eerder kroeg/concertzaal (met bediening(??)).

Wij bewaren de volgende gegevens:
prive: Voornaam, achternaam, emailadres, telefoonnummer, postcode, huisnummer, land.
reserveringonderdeel: dag en tijd reservering, werkelijke aankomsttijd/vertrektijd, gedrag klant, totale betaling, lidmaatschapskaart wel/niet, toepassen korting op basis van aantal reserveringen/totale betaling.

Je moet wel verdomd goed eten, goeie muziek EN goeie bediening hebben, wil ik dat allemaal achterlaten.
Voor een reservering ben in een restaurant kun je van mij krijgen: Naam, telefoonnummer en (eventueel) mailadres. Er is echt geen enkele reden dat een restaurant waar ik kom eten mijn adres ergens voor krijgt.
Verder vraag ik me ernstig af waar de werkelijke aankomst/vertrektijd voor opgeslagen moeten worden (sowieso... vertrektijd??). En 'Gedrag klant'...wat is dat?
Nope... ik wordt hier geen lid. En ik accepteer ook de cookies op de website niet, die ik overigens alleen maar bezoek met een adblocker en no-script.

Door de info die wij hebben is outsourcen geen optie. Verder denk ik ook niet dat de applicatie het probleem is, maar wel de koppeling vanuit de website naar de applicatie.

Dit ding is straks mooi om in MS PowerBI te zien, daar ben ik dan niet bang voor.

Verder ben ik enorm bewust van het AVG-verhaal. Ik weet dat ik al mijn data veilig moet stellen en liefst zoveel mogelijk "offline" bewaar. Maar naast het AVG-verhaal speelt imago ook een rol. Niemand wilt dat deze informatie op straat komt (bruikbaar of niet).

Niemand staat te wachten op een "account" op een website, maar de verplichting is er omdat wij te maken hebben met vele valse reserveringen van onze directe concurrenten. Uiteraard is bellen veel sneller dan de website. Maar als deze een paar reserveringen kan afhandelen dan is het voor de collega die de telefoon aanneemt iets rustgevend.

Als 10-20% via de website gedekt wordt is al voldoende.

AVG-technisch gaat het niet alleen om wat er op straat zou kunnen komen... maar ook om wat je op wilt slaan. En nogmaals... je wilt VEEL meer van me weten dan ik aan een restaurant, kroeg of concertzaal kwijt wil.

[DutchKel]

galaumiy schreef op maandag 19 augustus 2019 @ 15:19:
Wij bewaren de volgende gegevens:
prive: Voornaam, achternaam, emailadres, telefoonnummer, postcode, huisnummer, land.
reserveringonderdeel: dag en tijd reservering, werkelijke aankomsttijd/vertrektijd, gedrag klant, totale betaling, lidmaatschapskaart wel/niet, toepassen korting op basis van aantal reserveringen/totale betaling.

Wist je al dat je tegen de AVG in gaat door deze informatie zomaar op te slaan? De boetes zijn niet mals hiermee.

Je kunt als restauranthouder geen enkele geldige reden hebben om die informatie op te slaan van je klanten. Indien je dat wel hebt dan zou ik dat eerst een door iemand met AVG kennis laten toetsen of het wel legitiem is wat je wilt.

Tenzij je uiteraard een koffieshop hebt met softdrugs, volgens mij zijn dat de enige die alle gegevens mogen vastleggen van klanten.

[galaumiy]

Killjoy schreef op maandag 19 augustus 2019 @ 16:56:
Is dit een een wettelijke verplichting? Of is dit op eigen initiatief?

Initiatief van de vorige eigenaar, zodat dezelfde groep afgeweerd kunnen worden. Dit kan bijvoorbeeld wel weggelaten worden inderdaad. Ik ben erg blij dat je met deze vragen komt, hier kan ik iets mee en is ook bruikbaar als een sterk reden.

Als gebruikers in moeten loggen, dan bewaar je meer. Namelijk gebruikersnaam en wachtwoord (of hash ervan), informatie in logfiles, zoals (mogelijk) IP-adres, tijdstip en frequentie van bezoeken, zoekgedrag op de website, enz.

Doe je ook een leeftijdscheck bij aanmaak profiel op de site?

IP-adres wordt niet bewaard, ook de geboortedatum of leeftijdscheck wordt niet bewaard. Verder is er geen logs beschikbaar, ook omdat de data op een dedicated server bij een andere leverancier bewaard wordt.

Waarom niet dan?

De data die verzameld wordt is dan niet in ons beheer, omdat wij dan weer een nieuw systeem moeten leren gebruiken.

Dat is maar de vraag. Is het een applicatie die lokaal draait? Of is het een cloudtoepassing? Wie hebben toegang tot de server? Hoe is de beveiliging geregeld?

Goede vraag. Database draait bij een leverancier die de software ontwikkeld heeft. De applicatie draait zelf lokaal op een computer. Wij hebben geen toegang tot de managed server.

Maar wat ik dan mis is een uitleg over hoe je het dan technisch op wil zetten. Hoe wordt straks ingelogd. Pas je multifactor authenticatie toe? Pas je dataminimalisatie toe?

Alleen gebruikers die in het systeem voorkomen mogen registreren. Deze krijgen een uitnodigingscode tijdens het registreren. Dataminimalisalitie moet er zeker komen, al weet ik nog niet welke gegevens. Wij hebben veel te maken met terugkerende gasten.

Hoe ontsluit je data van de 'offline' applicatie naar de website; geef je na inlog in de beveiligde omgeving ook toegang tot alle eerder genoemde persoonsgegevens om op die manier invulling te geven aan het recht op inzage van de AVG? Of is het éénrichtingverkeer waarbij er alleen gegevens worden geschreven naar de back-end.

Dit is de reden ook waarom ik dit topic geopend heb. Liefst alles zoveel mogelijk beperken, maar wel de functionaliteit erin bouwen dat er gereserveerd kan worden. Eenrichtingsverkeer dus.

Als directe concurrenten een bedreiging zijn, kunnen ze je ook zieken door valse profielen aan te maken. Welke waarborgen heb je getroffen om dit te voorkomen? Kan iemand via de website een account aanmaken? Of kan dat alleen met tussenkomst van een beheerder? En hoe doe je de verificatie?

Er is altijd de tussenkomt van een beheerder noodzakelijk. Ook de reserveringen dienen goedgekeurd te worden.

[galaumiy]

Jeroenneman schreef op maandag 19 augustus 2019 @ 17:04:
Klinkt niet als een normaal restaurant. Waarom wil je in godsnaam een postcode en huisnummer vastleggen en wat vul je in bij "gedrag klant"?

En natuurlijk kunnen je concurrenten gewoon valse huisnummers invullen, dat is niet zo moeilijk. Net zoals het ook een koud kunstje is om een paar fake accounts aan te maken.

Geen idee, iniatief van de vorige eigenaar. Ik begrijp uit alle reacties dat het weglaten van de postcode en huisnummer niet belangrijk is. Ik zie de nut ook niet. Ik ga dit navragen waarom dit gebeurt en of dit straks ook noodzakelijk is. Wij hoeven deze info niet te bewaren inderdaad.

sypie schreef op maandag 19 augustus 2019 @ 17:44:
Het adres van de klant is helemaal niet interessant. Behalve wanneer het zo'n tent is waar geregeld de pleuris uitbreekt, dan is het handig dat je politie naar het juiste adres kunt sturen. Verder heeft een restaurant daar niks mee te maken.

Er bestaat ook zoiets als "teveel informatie willen hebben". Net als de grote bedrijven dat doen.

Ooit een keer bij een kapper geweest die wilde mij ook in z'n agenda zetten. Ik was daar al in de zaak om een afspraak te maken. Voor dit systeem hadden ze ook allerlei NAW gegevens nodig. Waarop mijn reactie was dat ik alleen maar geknipt hoefde te worden. Vervolgens kwam er een of ander excuus van hun kant om toch deze gegevens in te voeren. Waarop ik mijn excuses heb aangeboden, mij heb omgedraaid en het pand verlaten heb.

Ditzelfde zou ik voor een restaurant ook doen. Ook al zouden Jonnie en Thérèse Boer er naar vragen bij een reservering.

Voornaam, achternaam, telefoonnummer en mailadres. Meer hoef je niet en meer heb je niet nodig.

Bedankt voor je reactie. Ik neem dit mee. De oude eigenaar vond het handig, ook ik zie de nut ervan niet in.

Jester-NL schreef op maandag 19 augustus 2019 @ 19:34:
Ik lees hier niet "restaurant" maar eerder kroeg/concertzaal (met bediening(??)).
Het is een concert inderdaad, maar voor max 350 man.

Je moet wel verdomd goed eten, goeie muziek EN goeie bediening hebben, wil ik dat allemaal achterlaten.
Voor een reservering ben in een restaurant kun je van mij krijgen: Naam, telefoonnummer en (eventueel) mailadres. Er is echt geen enkele reden dat een restaurant waar ik kom eten mijn adres ergens voor krijgt.
Verder vraag ik me ernstig af waar de werkelijke aankomst/vertrektijd voor opgeslagen moeten worden (sowieso... vertrektijd??). En 'Gedrag klant'...wat is dat?
Nope... ik wordt hier geen lid. En ik accepteer ook de cookies op de website niet, die ik overigens alleen maar bezoek met een adblocker en no-script.

Werkelijke aankomsttijd wordt bewaard om te kijken of de gast wel zijn reservering naleeft. Gedrag klant is manuele tekstveld waarbij wij aangeven dat bijvoorbeeld dat deze gast voor overlast heeft gezorgd en niet meer welkom is. Veelal is deze veld leeg.

Niet iedereen mag inschrijven, enkel de gasten die aanwezig waren ontvangen een uitnodigingscode om te mogen inschrijven.

AVG-technisch gaat het niet alleen om wat er op straat zou kunnen komen... maar ook om wat je op wilt slaan. En nogmaals... je wilt VEEL meer van me weten dan ik aan een restaurant, kroeg of concertzaal kwijt wil.

Ik ben met je eens. Dit is dan ook fijn om te weten. Met deze reden kan ik naar de eigenaar stappen en aangeven dat het bewaren van deze gegevens gevaarlijk kunnen zijn en verwijderd moeten worden. Ook daarom heb ik ook het topic geopend. Ik vind alle kritiek terecht en ben ook ermee eens. De informatie wat ik hier verzamel kan ik als argument gebruiken om deze data niet meer te verzamelen.

DutchKel schreef op maandag 19 augustus 2019 @ 19:55:
Wist je al dat je tegen de AVG in gaat door deze informatie zomaar op te slaan? De boetes zijn niet mals hiermee.

Je kunt als restauranthouder geen enkele geldige reden hebben om die informatie op te slaan van je klanten. Indien je dat wel hebt dan zou ik dat eerst een door iemand met AVG kennis laten toetsen of het wel legitiem is wat je wilt.

Tenzij je uiteraard een koffieshop hebt met softdrugs, volgens mij zijn dat de enige die alle gegevens mogen vastleggen van klanten.

De data is niet publiekelijk toegankelijk (tenzij de server gehackt wordt). Maar met de komst van een website met een koppeling kan dit veranderen. Daarom heb ik ook dit topic geopend, zodat ik dit kan voorkomen. Ik ben ook een type 'informatiebeveiliging gaat vóór mannetje' noem ik maar even. Ik ben het ook met je eens.

[ Voor 88% gewijzigd door galaumiy op 20-08-2019 01:33 ]

[DutchKel]

galaumiy schreef op dinsdag 20 augustus 2019 @ 01:20:
De data is niet publiekelijk toegankelijk (tenzij de server gehackt wordt). Maar met de komst van een website met een koppeling kan dit veranderen. Daarom heb ik ook dit topic geopend, zodat ik dit kan voorkomen. Ik ben ook een type 'informatiebeveiliging gaat vóór mannetje' noem ik maar even. Ik ben het ook met je eens.

Ik geef even als tip mee dat je even moet uitzoeken wat de AVG inhoud. Je denkt dat het over het beveiligen van informatie gaat maar het gaat veel verder. Er staat ook in dat je GEEN persoonlijke informatie mag opslaan tenzij je het echt nodig hebt voor de bedrijfsvoering en als je dat nodig hebt dan dien je dat te documenteren wat je exact opslaat en met welke reden. Als je word gecontroleerd en de reden is niet voldoende dan kun je al direct een boete krijgen en dan word je een paar maanden erna weer gecontroleerd om te kijken of de gegevens zijn verwijderd.

Er hoeft maar 1 persoon te zijn die doorgeeft dat jullie te veel informatie opslaan en je kunt een controle verwachten.

Natuurlijk kun je als restauranthouder een bezorgdienst aanbieden waardoor je het adres nodig hebt om te kunnen bezorgen, dan kun je dat beschrijven welke gegevens nodig zijn om een bezorgdienst aan te bieden. Maar na het bezorgen moet je het adres dan weer verwijderen tenzij de klant heeft aangegeven dat de gegevens opgeslagen mogen worden om in de toekomst sneller te kunnen bestellen en dat dient dan uitgebreid beschreven te worden.

Dus nogmaals de AVG gaat veel verder dan de gegevens alleen maar encrypted opslaan.

Edit: Lees dit maar eens als voorbeeld (jij wilt iets anders maar wel vergelijkbaar, een vingerafdruk is een persoonsgegeven, een adres is dat ook), dan zie je hoe ver het gaat: https://www.nu.nl/tech/59...rplichten.html?redirect=1

[ Voor 8% gewijzigd door DutchKel op 20-08-2019 07:10 ]

[celshof]

Het lijkt mij slim om eens te starten met sites doorlezen als https://www.frankwatching.com/privacywet-avg-gdpr/ en https://www.kvk.nl/advies...-avg-hoe-zit-het-precies/

En dat jullie de data niet lokaal opslaan, maar bij een ander bedrijf betekent niet dat je daardoor een vrijbrief voor de AVG hebt.

[ Voor 26% gewijzigd door celshof op 20-08-2019 07:15 ]

[elhopo]

Wat als je maar een paar gegevens op de website bijhoudt? Een inlognaam en een wachtwoord bijvoorbeeld? Het controleren is een manueel proces, daar kan je een mail sturen met de bevestiging. Ik zie het even zo voor me:

Klant logt in met een naam en wachtwoord. Klanten hebben een iets hoger niveau dan niet ingelogde gebruikers. Hierdoor zien ze formulier x, waarmee ze kunnen reserveren. Na invullen wordt dit formulier gemaild naar de beheerder. Deze voert het in in het restaurantsysteem en stuurt een email ter bevestiging.

Op de website hou je zo vrijwel niets bij, enkel een inlogcode, een naam van de klant en een wachtwoord. Zelfs de reserveringsaanvraag sla je niet op, die wordt meteen gemaild. Geen risico's of wat dan ook lijkt me.

[DutchKel]

elhopo schreef op dinsdag 20 augustus 2019 @ 09:04:
Wat als je maar een paar gegevens op de website bijhoudt? Een inlognaam en een wachtwoord bijvoorbeeld? Het controleren is een manueel proces, daar kan je een mail sturen met de bevestiging. Ik zie het even zo voor me:

Klant logt in met een naam en wachtwoord. Klanten hebben een iets hoger niveau dan niet ingelogde gebruikers. Hierdoor zien ze formulier x, waarmee ze kunnen reserveren. Na invullen wordt dit formulier gemaild naar de beheerder. Deze voert het in in het restaurantsysteem en stuurt een email ter bevestiging.

Op de website hou je zo vrijwel niets bij, enkel een inlogcode, een naam van de klant en een wachtwoord. Zelfs de reserveringsaanvraag sla je niet op, die wordt meteen gemaild. Geen risico's of wat dan ook lijkt me.

Als een reserveringsaanvraag wordt gemaild dan wordt die ook opgeslagen en wel op de mailserver en/of mailclient.

Maar je moet zelfs een goede reden hebben om een naam op te slaan voor een langere tijd, anders mag je die alleen gebruiken waar je die voor nodig hebt. Dus tot de reservering en erna verwijderen.

Overigens als de klant login een e-mail adres is dan ben je ook al met persoonsgegevens bezig.

[Icephase]

celshof schreef op dinsdag 20 augustus 2019 @ 07:15:
Het lijkt mij slim om eens te starten met sites doorlezen als https://www.frankwatching.com/privacywet-avg-gdpr/ en https://www.kvk.nl/advies...-avg-hoe-zit-het-precies/

En dat jullie de data niet lokaal opslaan, maar bij een ander bedrijf betekent niet dat je daardoor een vrijbrief voor de AVG hebt.

Sterker nog, als de data bij een derde partij staat zijn er zelfs extra eisen waaronder een verwerkersovereenkomst.

@galaumiy Dataverwerking is tegenwoordig echt niet meer iets dat je er zomaar ff bij doet of waar je onzorgvuldig mee om mag gaan. Ook het verzamelen van data 'omdat het handig is' is echt niet meer zomaar toegestaan. Zorg er daarom ajb voor dat je het serieus aanpakt, óf dat je het aan een ander over laat.

[DukeBox]

sypie schreef op maandag 19 augustus 2019 @ 17:44:
Voornaam, achternaam, telefoonnummer en mailadres. Meer hoef je niet en meer heb je niet nodig.

Zou zelfs niet eens weten waarom de combinatie van voor en achternaam nodig is. Zeker met mensen waar de combinatie vrij uniek is zit je daar niet op te wachten.
Reserveren kan gewoon op 'naam' of dat nu voor, achter, bedrijfs- of zelfs gewoon een nummer is maakt niet uit.

[Verwijderd]

Wat ik hier voornamelijk tussen de regels lees is dat je op zoek bent naar een oplossing voor de huidige situatie, zonder die situatie eens onder de loep te leggen.

Persoonlijk denk ik dat dit een ultiem moment is voor "de schone lei"

Leg alles eens naar je neer, kijk naar de situatie en wat je echt wilt en nodig hebt. Dat het nu toevallig zo ingericht is, betekend niet dat het een goed uitgangspunt is.

[Killjoy]

galaumiy schreef op dinsdag 20 augustus 2019 @ 01:18:
Initiatief van de vorige eigenaar, zodat dezelfde groep afgeweerd kunnen worden. Dit kan bijvoorbeeld wel weggelaten worden inderdaad. Ik ben erg blij dat je met deze vragen komt, hier kan ik iets mee en is ook bruikbaar als een sterk reden.

Goed, het gaat dus eerder om een etablissement zonder vrije toegang waar door de eigenaar/uitbater zelf opgestelde gedragsregels gelden voor de gasten. Dat is op zich geen bezwaar onder de AVG, maar je zult de gedragsregels wel vooraf moeten communiceren aan de bezoekers. Idem voor de consequenties bij het niet naleven daarvan. Waaronder dus registratie van waarnemingen die door het personeel worden gedaan. Dan is het zeker gewenst dat ze daar expliciet mee akkoord gaan.

Je zal wel moeten bepalen wat de wettelijke grondslag (AVG) is voor de gegevens die je vastlegt. En je zult bewaartermijnen moeten bepalen. Ook mag je alleen persoonsgegevens verwerken die je echt nodig hebt voor je bedrijfsdoeleinden. Dus denk na over wat je waarvoor nodig hebt en voor hoe lang.

IP-adres wordt niet bewaard, ook de geboortedatum of leeftijdscheck wordt niet bewaard. Verder is er geen logs beschikbaar, ook omdat de data op een dedicated server bij een andere leverancier bewaard wordt.

Met leveranciers kun je afspraken maken over logging en logfiles. Die heb je nodig om te kunnen bepalen wanneer je een account van een niet langer actieve gast gaat verwijderen. En het hebben van logging is verstandig bij, bijvoorbeeld, een vermoeden van computervredebreuk.

Heb je trouwens bewakingscamera's in en om het pand? En film je in de zaal? Ook daar gelden eisen voor: https://autoriteitpersoon.../onderwerpen/foto-en-film

Goede vraag. Database draait bij een leverancier die de software ontwikkeld heeft. De applicatie draait zelf lokaal op een computer. Wij hebben geen toegang tot de managed server.

Het feit dat jij persoonsgegevens opslaat bij een andere partij, betekent dat deze verwerker in de zin van de AVG is. En jullie de verwerkingsverantwoordelijke. Dit betekent dat je een verwerkersovereenkomst moet sluiten met de leverancier. Het maken van afspraken over wat een acceptabel niveau van beveiliging is, maakt daar deel van uit. Vraag ook na of de gegevens binnen de EU/EER blijven. En liefst niet in het VK, i.v.m. Brexit.

Sites als Frankwatching zijn handig om info over de AVG op te doen. En deze van de AP voor algemene info: https://autoriteitpersoon...-voor-jou-of-jouw-bedrijf

Alleen gebruikers die in het systeem voorkomen mogen registreren. Deze krijgen een uitnodigingscode tijdens het registreren. Dataminimalisalitie moet er zeker komen, al weet ik nog niet welke gegevens. Wij hebben veel te maken met terugkerende gasten.

Terugkerende gasten zijn geen probleem. Bepaal wel na hoeveel tijd je een account verwijderd. Denk ook aan een privacyverklaring op de site waarin je informatie geeft over wat je verwerkt, waarom je dat doet, hoe lang je het bewaart, hoe iemand een verzoek tot inzage in kan dienen, enz.

[Yucon]

Waarom zijn nepreserveringen geen probleem bij telefonische reserveringen?

[galaumiy]

Dag allemaal,

Ik heb zojuist opdracht gegeven aan de software ontwikkelaar om de adresgegevens te verwijderen, hier heb ik namelijk akkoord op gekregen.

De koppeling van de website naar reserveringssysteem komt ook niet meer. Wij ontvangen e-mails en voeren de ontvangen e-mails zelf in dit systeem. Alle data blijft zo veilig, omdat de leverancier een s2s-verbinding naar de restaurant heeft. Ook mobiel is de data opvraagbaar, indien VPN actief.

[DJMaze]

galaumiy schreef op donderdag 22 augustus 2019 @ 13:10:
Alle data blijft zo veilig, omdat de leverancier een s2s-verbinding naar de restaurant heeft.

Dat is per definitie nog niet veilig.
Welke maatregelen neemt de leverancier op de s2s verbinding om het veilig te maken?

[galaumiy]

DJMaze schreef op donderdag 22 augustus 2019 @ 16:33:
[...]

Dat is per definitie nog niet veilig.
Welke maatregelen neemt de leverancier op de s2s verbinding om het veilig te maken?

Tsja, waar zou de leverancier nog meer op moeten letten? Hoe gek moet ik het maken?