Avvikshåndtering: brudd på personopplysningssikkerheten

Versjon 1.1, 5. november 2026.

Dokumentet utdyper databehandleravtalen punkt 8.2. Det gjelder brudd i Målfrid, der Schoolhub er databehandler og kommunen er behandlingsansvarlig. Brudd på nettstedet malfrid.eu, der Schoolhub er behandlingsansvarlig, følger kapittel 8.

1. Roller og frister

Fristen på 72 timer kan begynne å løpe når Schoolhub varsler, fordi kommunen da er kjent med bruddet. Derfor må varselet komme raskt og være kvalitetssikret. Kommunen melder selv til Datatilsynet, med skjemaet på https://www.datatilsynet.no. Schoolhub melder aldri til Datatilsynet på kommunens vegne uten instruks.

2. Hva er et brudd

Et brudd på personopplysningssikkerheten er et sikkerhetsbrudd som fører til utilsiktet eller ulovlig tilintetgjøring, tap eller endring av personopplysninger, eller til at uvedkommende får dem utlevert eller får tilgang til dem (art. 4(12)). Eksempler i Målfrid:

• Data fra én kommune vises for en annen kommune.
• En konto, en nøkkel eller oppsettet for pålogging er kompromittert.
• En ansatt hos Schoolhub leser kundedata uten tjenstlig behov.
• Innhold i en dataklasse sendes til en leverandør som kommunen ikke har tillatt for klassen, eller en leverandør lagrer eller trener på data i strid med avtalen.
• Skjulte instruksjoner i en tekst (prompt injection) får modellen til å utlevere data.
• Data går tapt, blir ødelagt eller slettes ved en feil.
• Innsynsmodulen utleverer taushetsbelagte opplysninger.
• En hendelse hos en underdatabehandler.

Ikke alle sikkerhetshendelser er brudd på personopplysningssikkerheten. Nedetid uten tap eller endring av data er et avvik i tilgjengelighet, men kan være et brudd hvis personopplysninger blir utilgjengelige. Mistanke om brudd varsles som om det var et brudd.

3. Fremgangsmåte

Oppdage → Registrere → Vurdere → Avgrense → Varsle kommunen (innen 24 timer) → Bistå kommunen
        → Utbedre og gjenopprette → Etterarbeid (innen 5 virkedager) → Lukke og lære

3.1 Oppdage

Hendelser oppdages gjennom alarmer fra overvåkingen, avviste forespørsler per enhet, uvanlig bruk, hendelser i påloggingstjenesten og revisjonsloggen, og gjennom meldinger fra kunder, underleverandører, sikkerhetsforskere og ansatte. Alle ansatte hos Schoolhub melder mistanke til sikkerhetsvakten straks.

3.2 Registrere

Vakten oppretter en hendelsessak med tidslinje i UTC. Tidspunktet for oppdagelsen starter fristen på 24 timer. Vakten utpeker en hendelsesleder og en som fører logg.

3.3 Vurdere

Vi vurderer straks:

1. Er personopplysninger berørt, og hvilke kommuner og enheter gjelder det?
2. Hvilke dataklasser og kategorier er berørt, også særlige kategorier? Omtrent hvor mange registrerte og poster?
3. Gjelder bruddet konfidensialitet, integritet eller tilgjengelighet?
4. Pågår det fortsatt?
5. Hvor alvorlig er det? Vi skiller mellom høy alvorlighet (brudd, lekkasje mellom kommuner, kompromittering, full nedetid), middels og lav.

Ved høy alvorlighet eller usikkerhet varsler vi kommunen innen fristen og venter ikke på full avklaring.

3.4 Avgrense og sikre bevis

Vi kan slå av en leverandør, trekke tilbake nøkler, slå av et påloggingsoppsett, stanse eller rulle tilbake en utrulling, isolere berørte tjenester og bytte hemmeligheter. Vi sletter ikke logger. Relevante deler av revisjonsloggen fryses, og vi tar øyeblikksbilder av berørte ressurser. Revisjonsloggen brukes til å avgrense hendelsen til aktør, objekt og tidsrom, og kontrollsummene brukes til å sjekke om loggen er endret.

3.5 Varsle kommunen (innen 24 timer)

Varselet sendes skriftlig på e-post og følges opp på telefon til kontaktpersonen kommunen har oppgitt ved oppstart. Vi bruker malen i kapittel 5. Det første varselet kan være kort. Vi sender oppdateringer fortløpende til saken er lukket.

3.6 Bistå kommunen

Vi gir kommunen det den trenger til meldingen til Datatilsynet (art. 33(3)): hva slags brudd det er, kategorier og omtrentlig antall registrerte og poster, kontaktpunkt (personvernombud), sannsynlige konsekvenser og tiltak. Vi gir også informasjon til varslingen av de registrerte (art. 34(2)) og svarer på spørsmål fra Datatilsynet. Kommunen avgjør om bruddet meldes, og fører sin egen oversikt over avvik. Vi hjelper kommunen med risikovurderingen etter art. 33 og 34: hvor sannsynlige og alvorlige konsekvensene er for de registrerte, blant annet om innholdet var kryptert og om nøkkelen er kompromittert.

3.7 Utbedre og gjenopprette

Vi retter årsaken, kontrollerer rettingen med tester og skanning, gjenoppretter fra sikkerhetskopi ved behov og overvåker tett etterpå. Er en modellleverandør kompromittert, slår vi den av, går gjennom loggen over leverandør og region for berørte kall og krever leverandørens hendelsesrapport.

3.8 Etterarbeid

Kommunen får en rapport senest 5 virkedager etter at saken er avsluttet. Rapporten har årsaksanalyse, tidslinje, hva som virket, og tiltak med ansvarlig og frist. Den peker ikke ut skyldige. Vi oppdaterer ROS-analysen, testene og ved behov DPIA, og går gjennom hendelsen internt. Alt lagres i avviksregisteret i minst 5 år (databehandleravtalen kapittel 7).

4. Varsling av de registrerte (art. 34): kommunens oppgave

Varsling kreves når bruddet sannsynligvis medfører høy risiko. Det gjelder unntak hvis (a) opplysningene var gjort uleselige for uvedkommende, for eksempel ved kryptering, (b) tiltak har fjernet den høye risikoen, eller (c) varsling ville kreve uforholdsmessig stor innsats. I tilfelle (c) skal det i stedet kunngjøres offentlig. Alt innhold i Målfrid er kryptert med en nøkkel som er egen for kommunen. Det kan gi unntak (a) ved lekkasje av en databasekopi eller fillagring, men bare hvis verken kommunens nøkkel eller nøkkelkrypteringsnøkkelen er kompromittert. Tekstvektorer, konfigurasjon (navn og beskrivelser) og søkeindeksen er ikke kryptert og må vurderes for seg. Teksten skal være i klarspråk (bokmål eller nynorsk). Den skal si hva som har skjedd, hvilke opplysninger som er berørt, mulige konsekvenser, hva kommunen gjør, hva den registrerte selv kan gjøre, og hvem den registrerte kan kontakte. Schoolhub skriver utkast når kommunen ber om det.

5. Maler

5.1 Første varsel til kommunen (innen 24 timer)

Emne: [HASTER] Mulig brudd på personopplysningssikkerheten i Målfrid, sak [saksnummer]

Til: [kommunens kontaktperson for informasjonssikkerhet], kopi: personvernombud [navn]
Fra: Schoolhub AS, [navn, telefon]
Tidspunkt for varsel: [dato og klokkeslett, UTC og norsk tid]
Tidspunkt for oppdagelse: [dato og klokkeslett]

1. Hva har skjedd (kort): [beskrivelse, med det vi vet og ikke vet]
2. Berørte enheter hos dere: [liste eller «under avklaring»]
3. Kategorier av opplysninger: [identitet / innhold / revisjonslogg / lyd]; dataklasser: [kommunens dataklasser]; særlige kategorier: [ja / nei / ukjent]
4. Omtrentlig antall registrerte og poster: [tall eller «ukjent»]
5. Type brudd: [konfidensialitet / integritet / tilgjengelighet]
6. Foreløpige konsekvenser: [vurdering]
7. Tiltak vi har satt i verk: [avgrensning, tilbakekalling av nøkler, leverandør slått av]
8. Tiltak vi anbefaler at dere vurderer: [for eksempel å avslutte økter, varsle brukere]
9. Hva vi ikke vet ennå: [liste]
10. Neste oppdatering: [dato og klokkeslett]
11. Kontaktpunkt hos oss: [navn, telefon, e-post]

Vi gir dere informasjon til vurderingen av melding til Datatilsynet (72 timer fra dere ble kjent med bruddet)
og til eventuell varsling av de registrerte. Revisjonsloggen er sikret.

5.2 Oppfølgingsrapport

Saksnummer: [nummer]   Versjon: [n]   Status: [pågår / avgrenset / lukket]
Tidslinje (UTC): [oppdaget, avgrenset, utbedret, varslet kommunen, ...]
Årsak (rotårsak): [...]
Berørte: [enheter, antall registrerte, kategorier; presisert fra første varsel]
Konsekvenser for de registrerte: [...]
Tiltak utført eller planlagt (ansvarlig og frist): [...]
Underdatabehandler involvert: [ja / nei, hvem, rapport vedlagt]
Hva dere som behandlingsansvarlig må vurdere: [melding til Datatilsynet, art. 34]
Dokumentasjon vedlagt: [utdrag fra revisjonsloggen, skjermbilder, logger]

5.3 Utkast til melding til de registrerte (kommunen sender)

Emne: Informasjon om en hendelse som kan gjelde personopplysningene dine

[Kommunens navn] har fått beskjed om at [hva som har skjedd] i tjenesten Målfrid, som vi bruker til [formål].
Hendelsen skjedde [når]. Opplysninger som kan være berørt: [liste].
Mulige konsekvenser for deg: [liste].
Dette har vi gjort: [tiltak]. Dette kan du gjøre: [råd, for eksempel å bytte passord eller være oppmerksom på ...].
Kontakt: [personvernombud, telefon, e-post]. Du kan klage til Datatilsynet: https://www.datatilsynet.no.

5.4 Oppføring i avviksregisteret

Avviksregisteret føres også for nesten-uhell og for brudd som ikke meldes (art. 33(5)).

6. Øvelse

Vi øver på en datalekkasje før den første kommunen tar tjenesten i bruk, og deretter hvert år. Scenariene er lekkasje mellom kommuner, kompromittert nøkkel hos en leverandør, personopplysninger sendt til en leverandør som ikke er tillatt for klassen og en ansatt hos Schoolhub som skaffer seg tilgang. Målet er å vise at varselet går ut innen 24 timer.

7. Kontakt med underdatabehandlere

Scaleway (hosting) varsler Schoolhub om hendelser gjennom statussiden og sine kanaler for støtte og sikkerhet. GreenPT, Microsoft og Mistral AI har egne kontaktpunkt, se underdatabehandlere. Kommunen når Schoolhub om personvern og sikkerhet på kontakt@malfrid.eu.

8. Brudd på nettstedet (Schoolhub som behandlingsansvarlig)

Schoolhub vurderer selv og melder til Datatilsynet innen 72 timer når det kreves (art. 33(1)). Berørte, for eksempel de som har sendt inn kontaktskjemaet, varsles ved høy risiko (art. 34). Vi bruker samme vurdering og registrering som ellers.

Kilder

• GDPR art. 4(12), 33 og 34: https://eur-lex.europa.eu/eli/reg/2016/679/oj
• EDPB, Guidelines 9/2022 on personal data breach notification under GDPR: https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under_en
• ROS-analyse, databehandleravtale