Personvern i nytt fagsystem må inn før skjemaene

Tenk deg at personvernombudet åpner skjemaet i det nye fagsystemet og finner fritekstfeltet «Andre opplysninger». Feltet er kopiert fra det gamle systemet, og ingen kan forklare hva det skal brukes til. Et felt som ingen kan forklare formålet med, skal ikke inn.

Når kommunen får et nytt fagsystem, er det fristende å la personvernet bli et punkt i siste fase, rett før systemet settes i drift. Da er datamodellen ferdig og skjemaene laget, og det som burde vært et designvalg, blir en lapp som limes på til slutt. Sjekklisten under er laget for å brukes tidlig, mens det fortsatt er enkelt å endre.

Sjekklisten før systemet tas i bruk

Tabellen kan skrives ut og brukes alene. Hvert punkt har et svar som noen må eie, og et tidspunkt i prosjektet der svaret bør være på plass.

Resten av artikkelen forklarer det som ikke får plass i en rute.

Hvilke personopplysninger systemet faktisk trenger

Kartleggingen starter med feltene, ikke med lovteksten. Gå gjennom hvert felt systemet skal ha, og still tre spørsmål: hva brukes opplysningen til, hvem leser den, og hva skjer i saken hvis den mangler? Et felt som ingen kan svare på, er et felt som ikke trengs.

Det vanligste problemet er arv. Feltlisten fra systemet du går bort fra, kopieres inn fordi den finnes, ikke fordi noen har vurdert den. Et nytt fagsystem er en sjelden anledning til å stille spørsmålet på nytt.

Se også etter fritekstfelt. De er nyttige for saksbehandleren, men de samler inn opplysninger ingen har planlagt for. Spør om fritekst trengs der den står, eller om et strukturert valg gjør samme jobben.

Mindre innsamling gir mindre å beskytte

Dataminimering høres ut som en juridisk plikt, og det er det, etter art. 5 nr. 1 bokstav c. Men det er også det enkleste sikkerhetstiltaket du har. En opplysning som aldri samles inn, kan ikke komme på avveie, trenger ingen sletterutine og trenger ikke forklares for den registrerte.

I praksis handler det om små valg i skjema og datamodell. Spør bare én gang om det samme. Ikke gjør felt obligatoriske fordi det er greit å ha dem. Hent ikke en hel person fra et register når saken bare trenger én opplysning. Og la standardvalget være det som samler minst.

Det lønner seg å la fagavdelingen og leverandøren gjøre denne gjennomgangen sammen. Fagavdelingen vet hva saken trenger, og leverandøren vet hva systemet henter i bakgrunnen.

Behandlingsgrunnlaget skal stå skriftlig

Hver behandling av personopplysninger trenger et grunnlag, og grunnlaget skal kunne vises fram. En kommune støtter seg normalt på art. 6 nr. 1 bokstav c eller e, med støtte i nasjonal lov, og sjelden på samtykke. Som vi skriver om automatisering og AI: automatisert behandling av personopplysninger krever et rettslig grunnlag og informasjon til den registrerte.

Det samme gjelder også når behandlingen ikke er automatisert. Skriv ned formålet, grunnlaget og hvilke opplysninger som inngår, og legg det der både fagavdelingen og personvernombudet finner det. Et grunnlag som bare finnes i hodet til prosjektlederen, forsvinner når prosjektet er ferdig.

Den andre halvdelen er informasjonen til de registrerte. Avklar hvor den skal stå, for eksempel i skjemaet eller i kommunens personvernerklæring, og at den beskriver det systemet faktisk gjør.

Sletterutinene må bygges, ikke bare skrives

En sletterutine på papir er et løfte. En sletterutine i systemet er en funksjon. Forskjellen merkes først når noen spør om opplysningene fortsatt finnes.

At rutinen er bygget, betyr at systemet kan slette eller anonymisere opplysninger etter en regel kommunen har bestemt, uten at noen må huske å gjøre det. Spør leverandøren om regelen kan settes per sakstype, om sletting kan skje automatisk, og om det blir dokumentert at den har skjedd.

Husk at noe skal bevares. Deler av en sak skal arkiveres, og da må regelen skille mellom det som skal arkiveres og det som skal slettes. Anonymisering kan være et godt mellomvalg når opplysningene trengs til statistikk, men ikke lenger trenger å kunne knyttes til en person.

Avtalen og stedet dataene ligger

Når leverandøren behandler personopplysninger på vegne av kommunen, trengs en databehandleravtale etter art. 28. Den bør dekke akkurat denne behandlingen og denne leverandøren, også underleverandørene. Underleverandører krever skriftlig forhåndsgodkjenning fra kommunen, og de må ha de samme pliktene. Hvorfor én avtale sjelden dekker alle, har vi skrevet om i Databehandleravtale: én avtale dekker ikke alle leverandørene.

Det siste punktet er hvor dataene ligger. For offentlige kunder holder vi data innenfor EU/EØS, og det bør være dokumentert, ikke antatt. Hvilke valg det innebærer når løsningen kjører i skyen, går vi gjennom i Azure for offentlig sektor: hvor data ligger, og hva dere må kunne dokumentere.

Les hvordan vi legger personvern inn i arkitekturen fra start.

Vanlige spørsmål

Hvem har ansvaret for personvernet i et nytt fagsystem? Som regel er kommunen behandlingsansvarlig, og leverandøren er databehandler når den behandler opplysninger på vegne av kommunen.

Må vi ha en databehandleravtale med leverandøren? Ja, når leverandøren behandler personopplysninger på vegne av kommunen.

Hva betyr dataminimering i praksis? At systemet bare samler inn opplysninger som trengs for formålet, og at resten ikke etterspørres.

Kan sletting gjøres manuelt? Det kan det, men det er sårbart. Det er bedre at systemet støtter sletting etter faste regler.

Må dataene ligge i Norge? Nei, personvernregelverket krever ikke at dataene ligger i Norge. Overføring ut av EU/EØS krever et gyldig overføringsgrunnlag, og derfor krever mange offentlige kunder at dataene blir innenfor EU/EØS.