DPIA for programvare som behandler barns data

Barns personopplysninger nyter et særskilt vern i personvernregelverket. Likevel behandles de hver eneste dag i programvare som barnehager, skoler og SFO bruker – oppmøte, beskjeder mellom hjem og institusjon, bilder, og noen ganger opplysninger om allergier, tilrettelegging eller helse. Det er nettopp denne typen behandling som ofte utløser et krav om vurdering av personvernkonsekvenser – en DPIA.

Men her oppstår forvirringen raskt: Hvem har egentlig ansvaret for DPIA-en – leverandøren av programvaren eller barnehagen som bruker den? Og hva må den faktisk inneholde for å holde mål? Denne artikkelen rydder opp i begge spørsmålene, sett fra en som jobber med både ISO 27005-risikostyring og personvern i praksis.

Hvorfor barns data er et særtilfelle

Personvernforordningen gir barn et forsterket vern. Begrunnelsen, som blant annet kommer til uttrykk i forordningens fortale, er enkel: barn er mindre i stand til å forstå konsekvensene av at opplysninger om dem behandles, og de kan i mindre grad ivareta egne interesser. I personvernsammenheng regnes barn derfor som sårbare registrerte – og det har en konkret betydning når man skal vurdere om en behandling utløser en DPIA.

Konsekvens: En behandling som kanskje ikke hadde krevd DPIA for voksne, kan kreve det når de registrerte er barn – fordi sårbarhet er ett av kriteriene som trekker risikoen oppover.

Når kreves en DPIA?

Utgangspunktet står i GDPR artikkel 35: en DPIA skal gjennomføres når en behandling «sannsynligvis vil medføre en høy risiko for fysiske personers rettigheter og friheter», særlig ved bruk av ny teknologi og sett i lys av behandlingens art, omfang, formål og sammenheng. Det er en skjønnsmessig vurdering – men du står ikke uten holdepunkter.

Det finnes tre kilder du må sjekke mot:

1. Datatilsynets liste

Datatilsynet har plikt til å publisere – og har publisert – en liste over behandlingsaktiviteter som alltid krever DPIA. Står behandlingen din på listen, er saken avgjort. Men listen er ikke uttømmende: du kan være forpliktet til DPIA selv om behandlingen ikke står der.

2. Artikkel 29-gruppens ni kriterier

Den europeiske personvernveiledningen (opprinnelig fra Artikkel 29-gruppen) opererer med ni kriterier som indikerer høy risiko. Tommelfingerregelen er at hvis behandlingen treffer to eller flere av kriteriene, bør du regne med at en DPIA er påkrevd. For programvare i barnehage- og skolesektoren er dette nesten alltid tilfellet:

Kriterium (Artikkel 29-gruppen)	Gjelder typisk barnehage-/skole-SaaS?
Sårbare registrerte	Ja – barn er per definisjon sårbare
Behandling i stor skala	Ofte – mange barn, mange institusjoner, over tid
Sensitive opplysninger / svært personlige data	Noen ganger – helse, allergi, tilrettelegging
Systematisk overvåking	Kan forekomme – oppmøte, lokasjon, aktivitet
Ny teknologi / innovativ bruk	Av og til – AI-funksjoner, ny analyse
Sammenstilling av datasett	Av og til – kobling mellom kilder
Evaluering eller scoring	Sjeldnere
Automatiserte avgjørelser med rettsvirkning	Sjeldnere
Behandling som hindrer en rettighet/tjeneste	Sjeldnere

Allerede de to øverste – sårbare registrerte i stor skala – tar deg som regel over terskelen.

3. Din egen konkrete vurdering

Selv om verken listen eller kriteriene treffer perfekt, må du gjøre en selvstendig vurdering basert på behandlingens art, omfang, formål og sammenheng. Og uansett konklusjon: risikoen skal vurderes løpende, ikke bare én gang.

Konsekvens: For en typisk barnehage-SaaS er det sjelden et spørsmål om hvorvidt en DPIA trengs – men om den er gjort, og om den er gjort godt nok.

Hvem har ansvaret – leverandøren eller barnehagen?

Dette er det punktet flest bommer på, så la oss være presise.

Den juridiske plikten til å gjennomføre en DPIA ligger hos behandlingsansvarlig – altså barnehagen, skoleeieren eller kommunen som bestemmer formålet med behandlingen. SaaS-leverandøren er normalt databehandler, og har ikke selv plikt etter artikkel 35 til å lage DPIA-en.

Men – og dette er hele poenget – en behandlingsansvarlig barnehage kan i praksis ikke gjennomføre en god DPIA uten informasjon fra leverandøren: dataflyt, hvilke kategorier opplysninger som behandles, hvor de lagres, bruk av underleverandører, og hvilke tekniske og organisatoriske tiltak som er på plass. Når en leverandør leverer et produkt som mange behandlingsansvarlige skal bruke til lignende behandlinger, er det både naturlig og ryddig at leverandøren stiller med en understøttende vurdering som kundene kan bygge sin egen DPIA på.

Konsekvens: Leverandøren må ikke lage DPIA-en, men leverandøren som gjør kundenes DPIA enklere, vinner anbud og avtaler. Dette er en av de mest oversette konkurransefordelene i markedet for barnehage- og skoleprogramvare.

Hva en DPIA skal inneholde

Artikkel 35 nr. 7 setter minimumskravene. I praksis består en god vurdering av fire deler:

1. En systematisk beskrivelse av behandlingen og formålene – hva behandles, av hvem, hvorfor, hvordan flyter dataene, og hvilke underleverandører er involvert.
2. En nødvendighets- og proporsjonalitetsvurdering – er behandlingen nødvendig for formålet, og står inngrepet i et rimelig forhold til det du oppnår? Behandler du mer enn du trenger?
3. En risikovurdering – hvilke konkrete risikoer finnes for barnas rettigheter og friheter, og hvor alvorlige og sannsynlige er de?
4. Planlagte tiltak – hva gjør du for å redusere risikoen til et akseptabelt nivå, inkludert garantier, sikkerhetstiltak og mekanismer som ivaretar de registrertes rettigheter.

Mye av råstoffet til en DPIA har du allerede, hvis du har orden i internkontrollen – behandlingsoversikt, databehandleravtaler og rutiner. Det DPIA-en krever i tillegg, er at du iverksetter tiltak utover minimumskravene der behandlingen utgjør en særskilt risiko. Her er ISO 27005-tankegangen et godt verktøy: identifiser, analyser, evaluer og behandle risikoen systematisk, og dokumentér beslutningene.

Den smarte leverandørens trekk: lever en DPIA-pakke

Hvis du leverer programvare til barnehage- eller skolesektoren, er dette det grepet jeg anbefaler oftest: lag en understøttende DPIA-pakke som kundene dine kan ta utgangspunkt i. Den bør inneholde en tydelig beskrivelse av dataflyt og databehandling, oversikt over underleverandører og lagringssteder, en redegjørelse for tekniske og organisatoriske tiltak, og en strukturert risikovurdering for de typiske bruksscenarioene.

Det erstatter ikke kundens egen vurdering – behandlingsansvarlig må alltid tilpasse den til sin konkrete bruk – men det reduserer terskelen for å ta dere i bruk dramatisk. En innkjøper i en kommune som får dette servert, slipper å starte fra blankt ark. Og det signaliserer at dere har personvern under kontroll, ikke bare som en påstand i salgsmaterialet.

Vanlige feil

• DPIA etter lansering. Vurderingen skal gjøres før behandlingen starter, og bør gjøres tidlig i en anskaffelse – ikke som en formalitet etter at løsningen er valgt. Det henger sammen med kravet om innebygd personvern.
• Klipp-og-lim. En generisk mal fylt ut overfladisk holder ikke. Vurderingen må være konkret for den faktiske behandlingen.
• Engangsdokument. En DPIA er en levende vurdering. Ny teknologi, nye funksjoner eller nye underleverandører utløser behov for oppdatering.
• Glemmer forhåndsdrøfting. Hvis det fortsatt gjenstår høy risiko etter at tiltakene er på plass, skal Datatilsynet kontaktes før behandlingen starter (se under).

Forhåndsdrøfting: når du må snakke med Datatilsynet

Hvis DPIA-en viser at det – selv etter planlagte tiltak – fortsatt foreligger en høy restrisiko, plikter behandlingsansvarlig å rådføre seg med Datatilsynet før behandlingen settes i gang. Dette kalles forhåndsdrøfting. Det er ikke en straff eller et nederlag; det er en sikkerhetsventil som lar deg få avklart en inngripende behandling før risikoen materialiserer seg. I praksis er målet å gjøre gode nok tiltak til at restrisikoen er akseptabel, slik at forhåndsdrøfting ikke blir nødvendig.

Hvordan SPADE Consulting kan hjelpe

Som ISO 27005 Lead Risk Manager og ISO 27001 Lead Implementer, med praktisk erfaring fra personvern- og sikkerhetsarbeid i nettopp barnehagesektoren, hjelper jeg både leverandører og behandlingsansvarlige med å gjøre DPIA-arbeidet riktig – og effektivt.

For leverandører bygger jeg understøttende DPIA-pakker som gjør kundenes vurderinger enklere og styrker dere i anbud. For barnehager, skoleeiere og kommuner gjennomfører jeg konkrete vurderinger som tåler et tilsyn. Som uavhengig konsulent i Bodø, uten overhead fra et stort byrå, kan jeg tilby seniorkompetanse til en fornuftig pris – og gjerne med fastpris på en definert DPIA-leveranse.

Trenger dere en DPIA – eller er dere usikre på om dere gjør?

Book et gratis, uforpliktende møte, så går vi gjennom behandlingen og avklarer hva som faktisk kreves.

Kilder og videre lesning

• Datatilsynet: Vurdering av personvernkonsekvenser (DPIA) – hovedveilederen
• Datatilsynet: Når må man gjennomføre en DPIA?
• Datatilsynet: Hvordan gjennomføre en DPIA – inkludert kravene i artikkel 35 nr. 7
• Personvernforordningen (GDPR): Artikkel 35 (vurdering av personvernkonsekvenser) og artikkel 36 (forhåndsdrøfting)

Sist oppdatert: Mai 2026. Artikkelen gir generell informasjon og er ikke juridisk rådgivning. Konkrete vurderinger må gjøres for den enkelte behandling.