GDPR artikkel 32 i praksis,
– og hvorfor sikkerhet må være normal drift
Det er lett å tenke at en databehandler “bare leverer systemet”, men når databehandler får bot, handler det om sikkerhet og personvern og at det faktisk må fungere i drift. Sportadmin-saken fra Sverige viser hvorfor det er en farlig forenkling. Den viser også noe mange undervurderer. Databehandler kan sanksjoneres direkte når personopplysningssikkerheten ikke står i forhold til risikoen.
Den svenske tilsynsmyndigheten IMY ga Sportadmin i Skandinavien AB et overtredelsesgebyr på 6 millioner SEK etter et cyberangrep som eksponerte personopplysninger om over 2,1 millioner mennesker. Mange av de berørte var barn og unge, og datasettet inkluderte blant annet personnummer og helseopplysninger.
Det mest interessante med saken er ikke bare at det ble et brudd. Det interessante er hva IMY mener burde vært på plass før angrepet skjedde, og hva dette betyr for leverandørstyring og dokumentasjon i praksis. Dette er en sak som viser hva som skjer når databehandler får bot.
Databehandler har selvstendig plikt til sikkerhet (GDPR artikkel 32)
IMY slår fast at kravet i GDPR artikkel 32 gjelder både behandlingsansvarlig og databehandler. I denne saken vurderer IMY at Sportadmin i hovedsak opptrer som databehandler for idrettslagene og foreningene som bruker plattformen. Likevel blir Sportadmin sanksjonert direkte.
Praktisk konsekvens er enkel. Du kan ikke “outsource” sikkerhetsansvar med en avtale. En databehandler må kunne vise at tekniske og organisatoriske tiltak faktisk fungerer i drift. Når en tjeneste håndterer store datamengder, sårbare grupper og sensitive opplysninger, blir kravene til sikkerhetsnivå høyere.
Kort om hendelsen
Angrepet ble oppdaget i januar 2025. IMY beskriver at angriperen utnyttet en sårbarhet som muliggjorde SQL-injeksjon i en del av løsningen som manglet tilstrekkelig beskyttelse mot denne typen angrep. Angrepet ga tilgang til store datamengder, og dataene ble senere publisert.
Saken fikk så alvorlige konsekvenser blant annet fordi:
- omfanget var stort
- mange registrerte var barn
- datasettene inneholdt personnummer og helseopplysninger
Hva IMY la vekt på
Det er lett å lese slike saker som “angriperen var dyktig”. IMY legger mer vekt på noe annet. De peker på mangler som samlet sett gjorde at sikkerhetsnivået ikke var tilpasset risikoen. Dette er klassiske punkter innen informasjonssikkerhet, men her blir de også personvern i praksis.
Blant momentene IMY fremhever, er dette særlig relevant for mange leverandører og virksomheter:
- Risikovurdering og sikkerhetsstyring: Risiko knyttet til løsningen var kjent over tid, uten at det ble gjort tilstrekkelige tiltak tidlig nok.
- Forebyggende kontroller: Beskyttelse mot kjente angrepsmetoder må være konsekvent og robust, særlig i eksponerte flater. Tiltak som WAF og annen beskyttelse kan være relevant når risikoen tilsier det.
- Overvåking og innbruddsdeteksjon: Overvåking som først varsler når systemet “stopper”, er ikke det samme som å kunne oppdage innbruddsforsøk tidlig.
- Tilgangsstyring og minste privilegium: For brede rettigheter i underliggende systemer gjør at et innbrudd får større omfang enn nødvendig.
- Kontinuerlig test og evaluering: Kontroller må testes og følges opp over tid, ikke bare “settes opp”. Dette gjelder også gjenoppretting og beredskap.
Dette er ikke “GDPR-papirarbeid”. Det er grunnleggende drift, sikkerhetsrutiner og hendelseshåndtering. GDPR artikkel 32 gjør det tydelig at dette også handler om personvern.
Hva betyr dette i praksis for norske virksomheter og kommuner?
Saken er spesielt relevant for virksomheter som bruker standardiserte plattformer, og for offentlige aktører med store datamengder og mange leverandører. Den er også relevant for alle som sitter i et IKT-samarbeid og må svare for helheten, ikke bare for egne interne systemer.
Hvis du skal bruke denne saken som læring, kan du starte med fire enkle spørsmål.
- Hvilke leverandører behandler de mest risikofylte datasettene våre?
Tenk barn, helse, personnummer, eller store volum. - Kan leverandøren dokumentere konkrete sikkerhetstiltak som faktisk brukes i drift?
Ikke bare policyer, men faktiske kontroller og rutiner. Det kan være logging, deteksjon, oppfølging av sårbarheter og praksis for tilgangsstyring. - Hvordan oppdages angrep tidlig, og hvordan begrenses skaden?
Det handler om innbruddsdeteksjon, overvåking, responstid, minste privilegium og klare roller ved hendelser. - Hva testes jevnlig?
Gjenopprettingstest, beredskapsøvelser, tilgangsrevisjoner og endringskontroll.
Normal drift slår dokumentdugnad
Mange jobber med databehandleravtaler og internkontroll som om det primært handler om dokumenter. Sportadmin-saken viser hvor det faktisk avgjøres.
Varig etterlevelse krever at sikkerhet og personvern er bygd inn i hverdagsrutinene. Det betyr at endringer i kode, drift og tilganger alltid vurderes med risiko i bakhodet. Dokumentasjonen fungerer best når den oppstår som en del av prosessen, og ikke som et prosjekt “i etterkant” når noen spør.
Faktaboks: Bruk saken som en anledning til å sjekke om leverandørstyringen deres fungerer i praksis. Det viktigste er å kunne vise rutiner og kontroller som faktisk brukes, ikke bare dokumenter som finnes.
- Avklar hvem som har admin-tilgang og hvordan tilgangsstyring følges opp
- Sjekk hvordan innbruddsdeteksjon og overvåking faktisk fungerer i drift
- Spør hva som testes jevnlig, inkludert gjenopprettingstest og beredskapsøvelser
- Be om en kort forklaring på hvordan sårbarheter håndteres over tid
- Sørg for at ansvar og rutiner er kjent av de som faktisk skal gjøre jobben
Lærdommen er enkel – For å unngå at databehandler får bot, må sikkerhet, tilgangsstyring og overvåking være normal drift.
Relatert lesning
Jeg har også skrevet en fagartikkel om databehandlere og databehandleravtaler, og hvordan leverandørstyring bør fungere i praksis. Den henger tett sammen med lærdommen fra denne saken.
