Versjon 1.2, 21. oktober 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 7.
1. Roller og tidsfrister
| Hvem | Plikt | Frist |
|---|---|---|
| Schoolhub (databehandler) | Varsle kommunen om brudd (GDPR art. 33(2), databehandleravtalen punkt 8.2) | Uten ugrunnet opphold, og senest 24 timer etter at bruddet eller en begrunnet mistanke ble oppdaget. Vi varsler også når informasjonen er ufullstendig |
| Kommunen (behandlingsansvarlig) | Melde til Datatilsynet hvis bruddet sannsynligvis medfører risiko for de registrertes rettigheter og friheter (art. 33(1)) | 72 timer etter at kommunen ble kjent med bruddet |
| Kommunen | Varsle de registrerte hvis bruddet sannsynligvis medfører høy risiko (art. 34) | Uten ugrunnet opphold |
| Kommunen | Dokumentere alle brudd, også de som ikke meldes (art. 33(5)) | Løpende |
| Underdatabehandler (for eksempel Scaleway, GreenPT, nexos.ai, Mistral AI, Staan og Microsoft) | Varsle Schoolhub uten ugrunnet opphold. Avtalen krever at varselet kommer så raskt at Schoolhub rekker fristen på 24 timer | Etter avtale |
72-timersfristen for kommunen kan starte når Schoolhub varsler, fordi kommunen da er kjent med bruddet. Rask og kvalitetssikret varsling er derfor viktig. Kommunen sender meldingen til Datatilsynet selv, via Datatilsynets skjema på https://www.datatilsynet.no. Schoolhub melder aldri til Datatilsynet på kommunens vegne uten instruks.
2. Hva er et avvik
Et brudd på personopplysningssikkerheten er et sikkerhetsbrudd som fører til utilsiktet eller ulovlig tilintetgjøring, tap, endring, ulovlig utlevering av eller tilgang til personopplysninger (art. 4(12)). Eksempler for Målfrid:
- Data fra én kommune vises for en annen kommune.
- En kompromittert konto, nøkkel eller påloggingsoppsett.
- En innsider hos Schoolhub leser kundedata.
- Innhold i dataklassen Personopplysninger sendes til feil leverandør, eller en leverandør lagrer eller trener på data i strid med avtalen.
- Skjulte instruksjoner i tekst (prompt injection) fører til at data utleveres.
- Tap eller ødeleggelse av data, eller feilaktig sletting.
- Innsynsmodulen utleverer taushetsbelagt informasjon.
- En hendelse hos en underdatabehandler.
Ikke alle sikkerhetshendelser er personvernbrudd. Ren nedetid uten tap eller endring av data er et tilgjengelighetsavvik. Det kan likevel være et brudd hvis det gjelder tilgjengeligheten til personopplysninger. Mistanke om brudd varsles som om det var et brudd.
3. Prosess
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, revisjonsloggen, og meldinger fra kunder, underleverandører, sikkerhetsforskere og ansatte. Alle ansatte hos Schoolhub melder mistanke til vakten for sikkerhet umiddelbart.
3.2 Registrere
Vakten oppretter en hendelsessak med tidslinje i UTC. Tidspunktet for oppdagelse starter 24-timersklokken. Vakten utpeker en hendelsesleder og en loggfører.
3.3 Vurdere
Vi vurderer umiddelbart:
- Er personopplysninger berørt, og hvilke kommuner og enheter gjelder det?
- Hvilke dataklasser og kategorier er berørt, herunder særlige kategorier? Omtrent hvor mange registrerte og poster?
- Gjelder bruddet fortrolighet, integritet eller tilgjengelighet?
- Pågår det fortsatt?
- Hvor alvorlig er det? Vi skiller mellom høy alvorlighet (brudd, lekkasje mellom kommuner, kompromittering, total 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, deaktivere 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 sikrer øyeblikksbilder av berørte ressurser. Revisjonsloggen brukes til å avgrense hendelsen på aktør, objekt og tidsrom, og kontrollsummene brukes til å sjekke om loggen er manipulert.
3.5 Varsle kommunen (innen 24 timer)
Varselet sendes skriftlig på e-post og følges opp på telefon til kontaktpersonen som kommunen har registrert i kundeoppsettet. Vi bruker malen i kapittel 5. Første varsel kan være kort. Vi sender oppdateringer fortløpende til saken er lukket.
3.6 Bistå kommunen
Vi gir kommunen informasjonen som trengs til meldingen til Datatilsynet (art. 33(3)): bruddets art, 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 meldingen sendes og fører egen avviksoversikt. Vi hjelper kommunen med risikovurderingen etter art. 33 og 34: sannsynlighet og alvor for de registrerte, blant annet om innholdet var kryptert og om nøkkelen er kompromittert.
3.7 Utbedre og gjenopprette
Vi retter årsaken, verifiserer rettingen med tester og skanning, gjenoppretter fra sikkerhetskopi ved behov og overvåker etterpå. Ved kompromittert modellleverandør slår vi av leverandøren, 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 inneholder årsaksanalyse, tidslinje, hva som fungerte, tiltak med ansvar og frist, og peker ikke ut skyldige. Vi oppdaterer ROS-analysen, tester og eventuelt DPIA, og gjennomgår 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. Unntak gjelder hvis (a) opplysningene var gjort uleselige for uvedkommende, for eksempel ved kryptering, (b) tiltak har fjernet den høye risikoen, eller (c) varsling krever uforholdsmessig stor innsats. Da skal det kunngjøres offentlig. Kryptering av innhold i dataklassene Konfidensiell og Personopplysninger kan gi unntak (a), men bare hvis nøkkelen ikke er kompromittert. Teksten skal være på klart språk (bokmål eller nynorsk). Den skal beskrive hva som har skjedd, hvilke opplysninger som er berørt, mulige konsekvenser, hva kommunen gjør, hva den registrerte kan gjøre og hvem hen kan kontakte. Schoolhub lager utkast på forespørsel.
5. Maler
5.1 Første varsel til kommunen (innen 24 timer)
Emne: [HASTER] Mulig brudd på personopplysningssikkerheten – Målfrid – [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 kjent og ukjent]
2. Berørte enheter hos dere: [liste eller «under avklaring»]
3. Kategorier av opplysninger: [identitet / innhold / revisjonsspor / lyd]; dataklasser: [Åpen / Intern / Konfidensiell / Personopplysninger]; særlige kategorier: [ja / nei / ukjent]
4. Omtrentlig antall registrerte og poster: [tall eller «ukjent»]
5. Type brudd: [fortrolighet / integritet / tilgjengelighet]
6. Foreløpige konsekvenser: [vurdering]
7. Tiltak iverksatt: [avgrensning, tilbakekalling av nøkler, leverandør slått av]
8. Tiltak vi anbefaler at dere vurderer: [for eksempel tilbakekalling av økter, varsling av brukere]
9. Hva vi ikke vet ennå: [liste]
10. Neste oppdatering: [dato og klokkeslett]
11. Kontaktpunkt hos oss: [navn, telefon, e-post]
Vi bistår med informasjon til deres vurdering av melding til Datatilsynet (72 timer fra deres kjennskap)
og eventuell varsling av de registrerte. Revisjonsspor 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 Intern loggoppføring (avviksregister)
| Felt | Verdi |
|---|---|
| Saksnummer | |
| Oppdaget (UTC) og varslet kommunen (UTC) | |
| Kunde(r) | |
| Type | Brudd, mistanke eller nesten-uhell |
| Alvorlighet | Høy, middels eller lav |
| Kategorier og antall berørte | |
| Rotårsak | |
| Tiltak, ansvarlig og frist | |
| Meldt til Datatilsynet av kommunen? | Ja eller nei, dato |
| Varslet registrerte? | Ja eller nei, dato |
| Rapport sendt (dato) | |
| Lærdom og endringer i ROS og tester | |
| Lukket (dato) |
Avviksregisteret føres også for nesten-uhell og for brudd som ikke meldes (art. 33(5)).
6. Øvelse
Vi gjennomfører en øvelse på datalekkasje før første kommune tar tjenesten i bruk, og deretter hvert år. Scenariene er lekkasje mellom kommuner, kompromittert leverandørnøkkel, feil leverandør for dataklassen Personopplysninger og innsiders tilgang. Målet er å vise at varsel går ut innen 24 timer.
6b. Kontakt hos underdatabehandlere
Scaleway (hosting) varsler Schoolhub om hendelser gjennom statussiden og sine støtte- og sikkerhetskanaler. GreenPT, nexos.ai, Mistral AI, Staan og Microsoft har egne kontaktpunkt, se underdatabehandlere. Kommunen når Schoolhub om personvern og sikkerhet på personvern@malfrid.eu.
7. Brudd på nettstedet (Schoolhub som behandlingsansvarlig)
Schoolhub vurderer selv og melder til Datatilsynet innen 72 timer hvis det er nødvendig (art. 33(1)). Berørte, for eksempel de som har sendt inn skjema, varsles ved høy risiko. Vi bruker samme vurdering og logging 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: https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under_en
- ROS-analyse, databehandleravtale