GDPR artikkel 32: hva regelmessig testing betyr

Artikkel 32 handler om sikkerhet ved behandlingen av personopplysninger. Kravet er at dere gjennomfører tekniske og organisatoriske tiltak som gir et sikkerhetsnivå egnet i forhold til risikoen. Hva som er egnet, avhenger av den tekniske utviklingen, kostnadene ved gjennomføringen, og behandlingens art, omfang, formål og sammenheng. Kravet er med andre ord relativt, og det er relativt med vilje.

Artikkelen nevner fire tiltak, alle kvalifisert med «etter behov». Pseudonymisering og kryptering. Evnen til å sikre konfidensialitet, integritet, tilgjengelighet og robusthet. Evnen til å gjenopprette tilgang etter en hendelse. Og bokstav d, den denne siden handler om: en prosess for regelmessig testing, analysering og vurdering av hvor effektive behandlingens tekniske og organisatoriske sikkerhetstiltak er.

Legg merke til hva bokstav d faktisk krever. Ikke en bestemt test, men en prosess. Ikke en frekvens, men ordet regelmessig. Ikke en metode, men en vurdering av om tiltakene virker. Det er et krav om at dere sjekker, og fortsetter å sjekke, at det dere har satt opp holder.

Digitalsikkerhetsloven treffer en smal krets av virksomheter. Personvernforordningen treffer i praksis alle. Har dere ansatte, ligger det personopplysninger i lønnssystemet. Har dere kunder som er mennesker, eller kontaktpersoner hos kunder som er selskaper, behandler dere personopplysninger om dem.

For de fleste norske små og mellomstore virksomheter er artikkel 32 derfor det sikkerhetskravet som faktisk gjelder dem, mens regelverkene som får mest omtale, NIS2 og digitalsikkerhetsloven, ikke gjør det. Spør noen hvilket regelverk som stiller sikkerhetskrav til akkurat dere, er dette som regel svaret.

Penetrasjonstest står ikke i artikkel 32. Sårbarhetsskanning står der ikke. Årlig står der ikke. Det er ikke et hull i regelverket, det er slik forordningen er bygget: den er teknologinøytral, fordi en lovtekst som navnga metoder ville låst metodene fra 2016 fast i loven.

Det betyr at ingen kan lese ut av forordningen at dere må kjøpe en penetrasjonstest, hverken årlig eller i det hele tatt. Det som kan leses ut av den, er at testing må skje, at den må skje regelmessig, og at dere må kunne gjøre rede for den. Får dere et tilbud med henvisning til at GDPR krever penetrasjonstest, be om å få se hvor det står.

De mest omtalte norske gebyrene for sviktende sikkerhet handler ikke om testing som manglet på et avansert nivå. De handler om grunnleggende tiltak som ikke var på plass, og om at ingen prosess fanget det opp.

Østre Toten kommune ble natt til 9. januar 2021 utsatt for et løsepengevirusangrep. Kommunens data ble kryptert og sikkerhetskopiene slettet, og kommunen anslo at rundt 30 000 dokumenter var omfattet. Datatilsynet ila et overtredelsesgebyr på 4 000 000 kroner. Manglene tilsynet pekte på var ikke subtile: tofaktorautentisering var ikke i bruk før hendelsen, backup-systemene var ikke tilstrekkelig sikret, og loggingen av viktige hendelser i nettverket var for tynn til å si hva som hadde skjedd.

Universitetet i Agder fikk et gebyr på 150 000 kroner i 2024, uten at noen hadde angrepet dem. En ansatt oppdaget i februar 2024 at dokumenter med personopplysninger hadde ligget i åpne Teams-mapper, tilgjengelige for ansatte uten tjenstlig behov, helt siden universitetet tok i bruk Teams i august 2018. Rundt 16 000 registrerte var berørt, og opplysningene omfattet blant annet navn, fødselsnummer og opplysninger om tilrettelagt eksamen.

Les de to sakene ved siden av bokstav d. En prosess som regelmessig hadde kontrollert hvem som hadde tilgang til hva, ville funnet Teams-mappene på en ettermiddag. En prosess som hadde prøvd en gjenoppretting fra sikkerhetskopi, ville funnet at kopiene kunne slettes. Det er dette testing betyr i artikkel 32, og det er fraværet av akkurat dette som har utløst gebyrene.

Prosessen skal stå i forhold til risikoen, og det betyr at den ser forskjellig ut hos en regnskapsfører med fem ansatte og hos en SaaS-leverandør med tusen brukere. Dette er byggeklossene, ordnet etter hvor mange de gjelder for.

Legg merke til hvor mye av dette som koster arbeidstid og ikke penger. Kravet i bokstav d kan for mange virksomheter oppfylles uten å kjøpe noe som helst.

Har dere en applikasjon med innlogging, og bak innloggingen personopplysninger som tilhører forskjellige brukere eller forskjellige kunder, endrer bildet seg. Om tilgangskontrollen holder, kan ikke leses ut av en tilgangsliste, og ingen automatisk skanning svarer på om bruker A kan hente ut opplysningene til bruker B. Det svaret finnes bare ved å prøve, innlogget, med flere roller.

Da er en sikkerhetstest den korteste veien til å vise at tiltakene virker, og rapporten dokumenterer begge deler: det som ble funnet, og det som ble undersøkt uten at noe ble funnet. Men rekkefølgen betyr noe. En rapport med åpne funn ingen har lukket, dokumenterer at dere fant noe og lot det ligge. Og en enkelt test uten en plan for den neste er et enkelttilfelle, ikke en prosess. Artikkelen sier regelmessig.

Test fordi dere vil vite svaret. Dokumentasjonen er det rapporten gir dere i tillegg, ikke grunnen.

Artikkel 5 nr. 2 krever at dere kan vise at reglene følges. For artikkel 32 betyr det at spørsmålet ikke bare er hva dere har gjort, men om dere kan legge fram at det skjer regelmessig, og at funn følges opp.

Det trenger ikke være en perm. En side er nok: hva som testes, hvor ofte, hvem som er ansvarlig, når det skjedde sist, og hva som ble gjort med det som ble funnet. Den siden, med ekte datoer i, er bedre dokumentasjon enn en tykk rapport fra ett enkelt år.

Denne siden bygger på forordningsteksten og på to vedtak fra Datatilsynet. Det er punktene under som skiller det vi vet fra det vi antar.

Den eksterne sjekken leser det som er synlig utenfra og gir dere funnene med en gang, uten innlogging og uten e-postadresse.