GDPR på hjemmesiden og i appen: sådan gør I i praksis

Det starter tit med en enkelt mail. En tidligere kunde skriver og beder om at få slettet alle sine oplysninger. Ejeren af virksomheden kigger efter og finder kundens navn i bookingsystemet, i nyhedsbrevsværktøjet, i den fælles indbakke, hvor kontaktformularen lander, i regnskabsprogrammet, i et gammelt regneark og i en optagelse fra et heatmap-værktøj, som marketing installerede for tre år siden. Ingen ved præcis, hvilke af stederne der må slettes, og hvilke der skal gemmes. Det er GDPR i virkeligheden: et spørgsmål om overblik.

Denne guide handler om GDPR i den software, I får bygget eller allerede har: hjemmeside, webshop, kundeportal og app. Vi er udviklere og designere, så vi fokuserer på de praktiske og tekniske dele. Den juridiske vurdering af jeres konkrete behandlinger hører hjemme hos en jurist, og Datatilsynets vejledninger er et godt sted at starte.

Hvad kræver GDPR af en hjemmeside eller app?

GDPR beskriver en række principper, som al behandling af personoplysninger skal leve op til. Oversat til software betyder de, at I skal kunne svare på seks spørgsmål for hver eneste type data: Hvorfor indsamler vi det? Hvad er grundlaget? Har vi brug for alle felterne? Hvor længe gemmer vi det? Hvem har adgang, også hos leverandører? Og hvordan beskytter vi det? Hvis I kan svare på dem, er I langt.

• Lovlighed og gennemsigtighed: et lovligt grundlag for hver behandling og en privatlivspolitik, der forklarer det i et sprog, kunderne forstår.
• Formålsbegrænsning: data indsamlet til en booking bruges til bookingen. Skal de bruges til markedsføring, kræver det sit eget grundlag.
• Dataminimering: spørg kun om det, I har brug for. Fødselsdato til et nyhedsbrev er sjældent nødvendig.
• Opbevaringsbegrænsning: faste slettefrister, der er bygget ind i systemet og ikke afhænger af, at nogen husker det.
• Integritet og fortrolighed: kryptering, adgangsstyring, logning og backup, der passer til risikoen.
• Ansvarlighed: I skal kunne dokumentere, at I lever op til reglerne, og det er her fortegnelse og aftaler kommer ind.

Hvordan laver man en dataoversigt for sin hjemmeside?

En dataoversigt er det vigtigste dokument, I kan lave. Gå hjemmesiden og appen igennem side for side og skriv ned, hvor der kommer personoplysninger ind: formularer, login, betaling, chat, analyse, nyhedsbrev, jobansøgninger og integrationer til andre systemer. For hvert sted noterer I, hvor data ender, og hvem der behandler dem. Tabellen herunder viser et typisk udsnit fra en servicevirksomhed med online booking.

Når oversigten er lavet, opdager de fleste to ting. Der er flere værktøjer, end nogen troede, og nogle af dem bliver ikke brugt mere. Det letteste GDPR-tiltag, I kan gøre, er at fjerne de scripts og integrationer, der ikke skaber værdi. Hver ekstra leverandør er en aftale, der skal holdes ved lige, og en mulig vej ud for data.

Hvilke leverandører kræver en databehandleraftale?

Alle, der behandler personoplysninger på jeres vegne. Det er typisk hosting, driftsleverandør og udvikler med adgang til produktionsdata, mailudbyder, nyhedsbrevsværktøj, CRM, supportsystem, analyseværktøj, chatwidget og betalingsløsning, hvor den ikke selv er dataansvarlig. Store SaaS-leverandører har en standardaftale, som I accepterer i deres vilkår. Mindre leverandører skal I ofte bede om den. Det vigtigste indhold er instruks, sikkerhed, tavshedspligt, brug af underdatabehandlere, overførsler uden for EU, hjælp ved brud og sletning eller tilbagelevering, når samarbejdet slutter.

Hvor data ligger, betyder meget, fordi overførsler til lande uden for EU og EØS kræver et særligt grundlag. Vi gennemgår mulighederne i guiden om hosting af data i EU. Det korte råd er, at EU-hosting gør aftalerne enklere, og at I altid bør kende listen over underdatabehandlere.

Hvornår skal man have samtykke, og hvornår ikke?

Mange tror, at GDPR betyder samtykke til alt. Samtykke er ét af seks grundlag, og for de fleste kernefunktioner i en hjemmeside eller app er et andet grundlag det rigtige. Når en kunde booker en tid, behandler I hendes adresse for at opfylde aftalen. Når I gemmer en faktura, gør I det, fordi loven kræver det. Samtykke bruges, hvor kunden reelt kan vælge til og fra uden at miste selve ydelsen: nyhedsbreve, ikke-nødvendige cookies, deling med samarbejdspartnere og lignende.

Cookies har deres egne regler oven i GDPR, og her er samtykke hovedreglen for alt, der ikke er strengt nødvendigt. Det gennemgår vi i guiden om regler for cookiebannere.

Hvordan håndterer man anmodninger om indsigt og sletning?

Brugere har ret til at få indsigt i deres data, få dem rettet, få dem slettet, når der ikke længere er grundlag for at have dem, og i visse tilfælde få dem udleveret i et maskinlæsbart format. I skal som udgangspunkt svare inden for en måned. I en løsning med ti kunder om året kan det klares manuelt. I en app med tusindvis af brugere bør det være en funktion. Apple kræver desuden, at apps med kontooprettelse lader brugeren slette kontoen inde i appen, hvilket vi uddyber i guiden om godkendelse i App Store.

Hvad med backups?

Backups er det spørgsmål, vi oftest får. Det er sjældent praktisk muligt at slette én person fra en krypteret backup, og det er heller ikke det, man normalt gør. I stedet roterer backups med en fast levetid, for eksempel 30 dage, og hvis en backup nogensinde gendannes, køres sletningerne igen. Beskriv det i databehandleraftalen og i privatlivspolitikken, så det er gennemsigtigt.

Logs, adgang og sikkerhed: hvad kræver GDPR teknisk?

GDPR kræver passende sikkerhed i forhold til risikoen, og den skal være indbygget fra start: privacy by design og by default. For en typisk forretningsløsning betyder det kryptering på vej og i hvile, login med stærke adgangskoder eller MitID og totrinsbekræftelse for administratorer, roller, så medarbejdere kun ser det, de skal bruge, logning af, hvem der har set og ændret data, og testede backups. Logs skal selv behandles forsigtigt: log hændelser og id’er og undgå at skrive navne, CPR-numre eller indholdet af beskeder i dem.

Vores tjekliste til IT-sikkerhed i software går i detaljer med 30 konkrete punkter. Behandler I følsomme oplysninger som helbred eller CPR-numre, stiger kravene, og så anbefaler vi en egentlig konsekvensanalyse og en jurist med fra starten.

GDPR-tjekliste til jeres hjemmeside og app

1. Lav en dataoversigt over alle steder, hvor personoplysninger kommer ind.
2. Notér formål, grundlag og opbevaringstid for hver type data.
3. Fjern formularfelter, scripts og værktøjer, I ikke har brug for.
4. Indhent databehandleraftaler fra alle leverandører, og gem dem ét sted.
5. Tjek, hvor data opbevares, og hvilke underdatabehandlere der bruges.
6. Skriv en privatlivspolitik i klart sprog, og link til den fra alle formularer.
7. Brug samtykke kun, hvor det er det rigtige grundlag, og gør det lige så let at trække tilbage.
8. Byg automatisk sletning efter faste frister ind i systemet.
9. Gør indsigt og sletning til en funktion, eller beskriv en manuel procedure, der kan nås på en måned.
10. Slå totrinsbekræftelse til for alle administratorer, og giv roller med mindst mulig adgang.
11. Log adgang til persondata uden at skrive persondata i loggen.
12. Aftal en procedure for databrud med jeres leverandør, så 72-timersfristen kan nås.

Hvad koster det at gøre en løsning GDPR-klar?

Bygges det ind fra start, er merprisen lille. Sletning efter faste frister, roller, logning og en eksportfunktion er typisk et par dages arbejde i en ny løsning. Det bliver dyrt, når det skal eftermonteres i et system, hvor kundedata ligger spredt i tabeller uden struktur, eller hvor ingen ved, hvilke integrationer der sender data videre. Et realistisk eksempel: en servicevirksomhed med 20 ansatte får lavet en ny bookingløsning med kundelogin. Dataoversigt og privatlivspolitik tager en workshop på et par timer. Automatisk sletning af inaktive kunder efter en fast periode, en knap til at slette konto og eksport af egne data indgår som tre af funktionerne i pakken, og databehandleraftalen med udvikleren underskrives sammen med kontrakten. Ingen af delene kræver et særskilt GDPR-projekt.

Hos os er sikkerhed og backup en del af den faste månedlige drift, og I ejer både kode og data, hvilket gør det let at dokumentere, hvor alt ligger. Læs mere om ejerskab i guiden hvem ejer koden. Skal I i gang med en ny løsning, så beskriv den i en kort forespørgsel, og vi sender en fast pris inden for 24 timer, hvor GDPR-funktionerne står listet.

Hvilke GDPR-fejl ser vi oftest i praksis?

Kontaktformularer, der sender alt til en fælles indbakke, som aldrig ryddes op. Testmiljøer med en kopi af den rigtige kundedatabase, som flere udviklere har adgang til. Gamle medarbejdere, der stadig har administratoradgang. Analyse- og marketingscripts, der indlæses, før brugeren har givet samtykke. Og nyhedsbrevslister, hvor ingen kan dokumentere, hvornår og hvordan folk tilmeldte sig. Alle fem kan løses på en dag eller to, når først nogen ejer opgaven. Vi anbefaler at lægge en årlig GDPR-gennemgang i kalenderen sammen med jeres leverandør.