GDPR ved kontaktformularen: de punkter, der betyder noget i praksis

Enhver kontaktformular behandler personoplysninger: et navn, en e-mailadresse, ofte et telefonnummer og en fritekstbesked, der kan indeholde næsten hvad som helst. GDPR forbyder intet af det, men stiller nogle få forventninger – til selve formularen, til det, der indlæses omkring den, og til hvad der sker med beskeden bagefter.

Ved formularen: oplys, og bed om lidt

Artikel 13 i GDPR kræver, at du oplyser folk på det tidspunkt, hvor du indsamler deres data. For en kontaktformular betyder det ved formularen – ikke kun via et link i sidefoden langt nede. Den almindelige tilgang er lagdelt: én kort sætning ved siden af send-knappen, f.eks. “Vi bruger kun dine oplysninger til at besvare din henvendelse – læs mere i vores privatlivspolitik”, med link til politikken. Politikken dækker så alle detaljerne.

Det andet princip er dataminimering (artikel 5, stk. 1, litra c)). For at svare har du som regel brug for en måde at svare på og selve beskeden. Et navn hjælper, et telefonnummer er sommetider nyttigt, en postadresse sjældent. Udelad det, du ikke har brug for, og marker felter, der er rare at have, som valgfrie. Forestil dig en tandlægeklinik, hvis formular gør telefonnummeret obligatorisk: Alle, der foretrækker e-mail, presses til at udlevere mere, end formålet kræver.

At besvare en henvendelse kræver som regel intet samtykkefelt

Mange formularer har et obligatorisk felt med teksten “Jeg giver samtykke til behandling af mine data”. Det ser omhyggeligt ud, men er som regel det forkerte værktøj. Når nogen stiller et spørgsmål eller beder om et tilbud, er retsgrundlaget typisk artikel 6, stk. 1, litra b) – foranstaltninger truffet på personens anmodning forud for indgåelse af en kontrakt – eller artikel 6, stk. 1, litra f), din legitime interesse i at svare. Samtykke medfører sine egne forpligtelser: Det skal være frivilligt og kan til enhver tid trækkes tilbage. Særlige kategorier af data er noget andet: Hvis en formular beder om helbredsoplysninger, f.eks. hos en læge- eller tandlægeklinik, gælder art. 9 GDPR, og retsgrundlaget kræver en særskilt vurdering.
Markedsføring er noget andet. Et nyhedsbrev kræver ægte samtykke: et separat afkrydsningsfelt, der som standard ikke er markeret – betragtning 32 fastslår, at forudmarkerede felter ikke tæller – og formularen skal fungere uden det.

Hvad der ellers indlæses på formularsiden

Felterne er sjældent alene på siden. En CAPTCHA fra en ekstern udbyder, en annonce- eller analysepixel eller et session replay-værktøj kan køre, mens nogen skriver. Hver af dem kan sende data – i det mindste IP-adressen – til en tredjepart, og lagring af eller adgang til oplysninger på enheden kræver generelt samtykke efter e-databeskyttelsesreglerne, som de er gennemført nationalt – i Tyskland og Polen som andre steder – medmindre det er strengt nødvendigt. Session replay er det mest følsomme: Uden maskering kan det optage, hvad folk skriver, før de overhovedet klikker på Send.
Det er her, samtykkebanneret skal levere: Efter “Afvis” skal pixels forblive tavse. Om en tredjeparts-CAPTCHA er strengt nødvendig, er omdiskuteret. Hvis den først indlæses efter samtykke, så giv dem, der har afvist, en anden måde at kontakte dig på, f.eks. en almindelig e-mailadresse. Beskyttelse uden tredjepart – et honeypot-felt, en tidskontrol, en proof-of-work-udfordring – undgår helt spørgsmålet.

• Åbn formularsiden i et privat vindue, afvis banneret, og tjek netværksfanen i udviklerværktøjerne: Hvilke eksterne forespørgsler går stadig ud?
• Tjek for annonce- og analysepixels på formularsiden og på taksiden efter afsendelse.
• Hvis du bruger session replay, så sørg for, at formularfelter er maskeret, eller at formularsider er udelukket.
• Notér, hvilken CAPTCHA-udbyder der indlæses, og hvornår – før eller efter samtykke.
• Nævn hver tilbageværende tredjepart med dens formål i din privatlivspolitik.

Hvor beskederne havner – og hvor længe de bliver

Enhver tjeneste, der håndterer beskederne på dine vegne – hosting, mailudbyder, en formular-SaaS, som formularen sender til, en helpdesk eller et CRM – er databehandler efter artikel 28 i GDPR. Du skal have en databehandleraftale med hver af dem; de fleste udbydere tilbyder en standardaftale. Hvis data behandles uden for EU/EØS, kræver overførslen også et grundlag efter kapitel V, f.eks. en tilstrækkelighedsafgørelse – såsom databeskyttelsesrammen mellem EU og USA (EU–US Data Privacy Framework) for certificerede virksomheder – eller standardkontraktbestemmelser.

Henvendelser bør ikke opbevares for evigt. Efter princippet om opbevaringsbegrænsning (artikel 5, stk. 1, litra e)) fastsætter du en opbevaringsperiode og sletter faktisk – også kopier i postkasser, plugin-databaser og CRM'et. Hvis en henvendelse bliver til et kundeforhold, kan handels- og skatteregler – både Tyskland og Polen har dem – kræve, at noget korrespondance opbevares i årevis; så er det den pligt, der fastsætter perioden. Endelig sikkerhed: Artikel 32 nævner kryptering som eksempel på en passende foranstaltning. En formular, der leveres uden HTTPS eller med et udløbet certifikat, sender personoplysninger ubeskyttet.

formexposed-scanneren ser udefra på flere af disse punkter: et link til privatlivspolitikken ved formularen, om afvisning af cookiebanneret virkelig stopper sporingen, pixels og session replay-værktøjer på formularsider, og om modtageradressen er synlig i sidens kildekode. Den indsender intet. En gratis kontrol uden konto giver dig det samlede niveau og de centrale fund om beskyttelse; GDPR-detaljerne findes i den fulde rapport.