Säkra kontaktformulär enligt GDPR

De flesta hemsidor har ett kontaktformulär, och de flesta hemsideägare tänker sällan på det som en plats där personuppgifter samlas in. Men så snart formuläret ber om namn, e-postadress eller ett fritextmeddelande hanterar ni personuppgifter enligt dataskyddsförordningen (GDPR), och samma grundkrav gäller som för andra register: samla in det som behövs, skydda det som skickas och sparas, och berätta för besökaren vad som händer med uppgifterna. Det handlar inte om att bygga om formuläret från grunden, utan om att gå igenom fem konkreta punkter en gång och sedan hålla dem uppdaterade.

Vad ett säkert kontaktformulär kräver

Ett formulär som lever upp till grundkraven har fyra byggstenar på plats: fälten samlar bara in det som faktiskt behövs för ärendet, överföringen sker krypterat, det finns en bestämd tidsgräns för hur länge meddelanden sparas, och besökaren får se en kort integritetstext innan uppgifterna skickas in. Tabellen nedan kopplar varje risk till en konkret åtgärd, vem som brukar ansvara för den och vilken källa åtgärden vilar på.

Samla in bara det du behöver

Gå igenom formulärets fält och fråga er för varje fält: används det faktiskt när ärendet hanteras? Namn och e-postadress behövs nästan alltid för att kunna svara, men fält som personnummer, adress eller telefonnummer är sällan nödvändiga för ett vanligt kontaktärende och bör vara valfria eller tas bort helt. Samma sak gäller dolda fält som samlar in mer än vad besökaren ser, till exempel extra spårningsdata som skickas med utan att det finns ett tydligt ändamål. Ju färre fält som är obligatoriska, desto mindre finns det att skydda och desto lättare blir det att förklara vad uppgifterna används till. Ett vanligt kontaktformulär brukar landa ungefär så här, fält för fält:

• Namn: behövs nästan alltid för att kunna svara personligt.
• E-postadress: behövs för att kunna skicka svaret.
• Telefonnummer: ofta onödigt om ni ändå svarar via e-post – gör det valfritt om inte ärendet kräver att ni ringer upp.
• Personnummer: nästan aldrig nödvändigt för ett vanligt kontaktärende, ta bort fältet om det saknar ett tydligt syfte.
• Adress: bara motiverat om ärendet faktiskt kräver fysisk leverans eller besök.
• Meddelande/fritext: nödvändigt för själva ärendet, men undvik att uppmana besökaren att skriva känsliga uppgifter där.
• Dolda eller tekniska fält: ta bara med dem om de har ett tydligt syfte, till exempel ett enkelt spamskydd, inte som standard.

Kryptera överföringen och sätt en lagringstid

Uppgifterna i formuläret ska färdas krypterat från besökarens webbläsare till er server, vilket i praktiken betyder att hela sajten, inte bara formulärsidan, ska ha ett giltigt SSL/TLS-certifikat och konsekvent HTTPS. En osäker anslutning gör innehållet läsbart för fler än avsändaren och mottagaren, och IMY förutsätter att den här typen av tekniska skyddsåtgärder anpassas efter risken i behandlingen. Kontrollera samtidigt vart meddelandena skickas vidare: hamnar de i en delad e-postinkorg, ett CRM eller ett formulärverktyg, och vem hos er som har åtkomst dit.

Lagringstiden är minst lika ofta förbisedd. Ett kontaktformulär utan gallringsrutin blir med tiden en samling gamla meddelanden som ingen längre har ett syfte med att spara, vilket strider mot principen om att inte lagra personuppgifter längre än nödvändigt. Bestäm en rimlig tidsgräns, till exempel att ärenden gallras eller arkiveras separat en viss tid efter att de är avslutade, och lägg in en påminnelse om att faktiskt genomföra gallringen i stället för att låta den bli en engångsinsats.

Spamskydd utan att bryta mot dataskyddskraven

Ett formulär utan spamskydd fylls snabbt av automatiserade inskick, men lösningen behöver inte innebära att ni delar mer data än nödvändigt med en extern part. Enklare tekniker som ett dolt honeypot-fält eller en gräns för hur många inskick samma avsändare kan göra på kort tid stoppar mycket automatiserad spam utan att skicka besökarens uppgifter någonstans alls. Om ni i stället använder en extern captcha- eller spamfiltertjänst som tar emot meddelandets innehåll eller besökarens IP-adress, behandla den leverantören som vilket personuppgiftsbiträde som helst: kontrollera vad tjänsten faktiskt samlar in, och se till att ett biträdesavtal finns innan tjänsten kopplas in, inte efteråt. Samma sak gäller andra tredjepartsverktyg kring formuläret, till exempel ett formulärplugin som mellanlagrar inskicken hos leverantören eller en tjänst som skickar e-postnotiser vidare till flera mottagare: så snart en extern part hanterar personuppgifterna räknas den som personuppgiftsbiträde, oavsett om det är captcha, spamfilter, formulärplugin eller notistjänst som är inblandad.

Vad integritetsinformationen vid formuläret ska innehålla

Besökaren ska kunna se, i nära anslutning till formuläret och inte bara i en generell policy längre bort på sajten, vad som händer med uppgifterna. En kort text räcker: vad uppgifterna används till, vilken laglig grund behandlingen stödjer, vem som tar emot dem (till exempel om ett formulärverktyg eller en supportfunktion är inblandad), hur länge de sparas, och hur besökaren gör om de vill fråga, rätta eller få uppgifterna raderade. Länka gärna vidare till en fullständig integritetspolicy för den som vill läsa mer, men låt inte hela informationen ligga dold där som enda källa.

Ett kort exempel som täcker det viktigaste kan se ut ungefär så här: "Uppgifterna du lämnar i formuläret används för att besvara ditt ärende. Vi sparar dem så länge ärendet är aktivt och en kort tid därefter, och lämnar dem inte vidare i något annat syfte. Vill du se, rätta eller få uppgifterna raderade, kontakta oss på [er e-postadress]. Läs mer i vår integritetspolicy." Anpassa texten efter er egen lagringstid och era egna rutiner i stället för att kopiera den rakt av.

Vanliga frågor