DBA – avtaleutkast

Databehandleravtale for skolebruk

Grunnlag for avtale mellom skoleeier og Fjord Service ved bruk av 321skole. Kan brukes sammen med skoleeiers egen avtalemal.

Arbeidsutkast v0.12. Innhold revidert: 12. november 2026.

Dette er et generelt avtaleutkast med bilagsgrunnlag for skoleeiers vurdering. Partene, behandlingsomfanget og bilagene skal avklares og gjennomgås juridisk før eventuell signering.

1. Parter, tjeneste og avtaledokumenter

Utkastet gjelder skolebruk av 321skole, med skoleeier som behandlingsansvarlig og Fjord Service som databehandler.

  • • Fjord Service Jan Hogne Christiansen (ENK), org.nr. 968 400 789. Adresse: Røysegata 19, 6003 Ålesund. Kontakt for personvern og avtale: post@321skole.no. Kommunens avtalepart og ansvarlige kontaktpersoner fylles inn i den konkrete avtalen.
  • • Skoleeiers registrerte navn, organisasjonsnummer og kontaktinformasjon fylles inn i avtalen. Avtaleperiode, hovedavtale, kontaktpersoner og signaturer avklares før signering.
  • • Bilag A beskriver behandlingen, bilag B sikkerhetstiltak og driftsrutiner, bilag C underdatabehandlere/overføringer og bilag D oppbevaring, tilbakelevering og sletting. Bilagene nedenfor er arbeidsgrunnlag, ikke ferdig utfylte avtalebilag.

2. Dokumenterte instrukser og formålsbegrensning

Ved kommunal skolebruk er avtaleoppsettet at kommunen/skoleeier bestemmer formål og behandlingsgrunnlag, og at Fjord Service behandler skoledata på kommunens dokumenterte instrukser. Egne leverandørformål, som fakturering og nødvendig drift av egne kundeforhold, må beskrives separat.

  • • Databehandler skal bare behandle skoledata etter dokumenterte instrukser, også ved overføring utenfor EØS. Pålagte lovkrav og eventuell ulovlig instruks skal håndteres og meddeles kommunen etter gjeldende regelverk.
  • • Skoledata skal ikke selges eller brukes til tredjepartsannonsering eller reklameprofiler. Analyse, drift og eventuell produktforbedring må ha uttrykkelig beskrevet formål og grunnlag; dette er ikke en generell tillatelse til gjenbruk av elevarbeid.

3. Tilgang, taushetsplikt og sikkerhet

Tilgang skal begrenses til autoriserte personer med tjenstlig behov og taushetsplikt. Tekniske og organisatoriske tiltak skal konkretiseres i bilag B og holdes oppdatert.

  • • Avtalt rollemodell: skoleadministrator administrerer bare egen skoles lærere innenfor lisensen og får aggregert skolestatistikk. Rollen alene skal ikke gi tilgang til individuelle elevsvar, KI-feedback eller undervisningsrom. En administrator som også er lærer får egne undervisningsrettigheter gjennom lærerrollen.
  • • Skolegrensen for nye medlærer- og observatørinvitasjoner til skolerom er innført og kontrollert 6. november 2026. Lærere som inviteres, må ha aktiv tilknytning til samme skole. Skoleadministratorrollen gir ikke i seg selv innsyn i individuelle elevsvar eller rett til å invitere på vegne av romeier.
  • • Tidsbegrenset vikartilgang er innført og kontrollert 7. november 2026. Skoleadministrator kan gi en lærer med aktiv tilknytning til samme skole tilgang til et bestemt skolerom, også ved lærerfravær. Vikaren kan lese oppgaver og elevsvar og gi skriftlig tilbakemelding gjennom en egen avgrenset visning. Tilgangen kan trekkes tilbake og utløper automatisk. Tildeling, utløpsfrist og tilbakekalling loggføres. Tilgangen gir ikke ordinære administrasjonsrettigheter i rommet eller generell tilgang til skolens øvrige rom.

4. Bistand til kommunen og registrerte

Databehandler skal bistå kommunen med rettighetsforespørsler, sikkerhet, risikovurdering/DPIA og nødvendig oppfølging av personvernkrav ut fra behandlingens art og tilgjengelig informasjon.

  • • Forespørsler om innsyn, retting, sletting, begrensning og eventuell utlevering håndteres etter kommunens verifiserte instruks. Identitet og rett til å representere kommunen må kontrolleres før utlevering.
  • • Kontaktpunkt er post@321skole.no. Svartider og eventuelle kostnader for bistand avklares i avtalen.

5. Brudd på personopplysningssikkerheten

Databehandler skal varsle kommunen uten ugrunnet opphold etter å ha blitt kjent med et brudd og bistå med tilgjengelig informasjon om hendelsen, berørte data, følger og tiltak.

  • • Varslingsmottakere, stedfortredere, alternativ varslingskanal, eskalering og beredskapsrutiner fastsettes og verifiseres i bilag B.

6. Underdatabehandlere og internasjonale overføringer

Lagring i en europeisk region betyr ikke at all behandling skjer i EØS. Autentisering, serverbehandling, support, logger, KI og e-post må vurderes hver for seg. Avtalepart, behandlingsland, relevant overføringsgrunnlag og eventuelle tilleggstiltak skal bekreftes per leverandør.

  • • Bruk av underdatabehandlere krever kommunens spesifikke eller generelle skriftlige godkjenning. Ved generell godkjenning skal planlagte tillegg/utskiftinger varsles slik at kommunen kan protestere. Ordning, frist og konsekvens av innsigelse fastsettes før signering.
  • • Relevante plikter skal videreføres til underdatabehandlerne. Generelle henvisninger til SCC-er eller EU-lagring dokumenterer ikke alene at det konkrete avtale- og overføringsoppsettet er avklart.

7. Dokumentasjon, revisjon og endringer

Databehandler skal gjøre relevant dokumentasjon tilgjengelig og bidra til revisjoner/inspeksjoner som kommunen eller dens autoriserte revisor gjennomfører. Omfang, praktisk gjennomføring og vern av andre kunders data avtales.

  • • Vesentlige endringer i funksjoner, behandlingsformål, datakategorier eller sikkerhet skal vurderes mot kommunens instrukser og avtalens bilag før de inngår i skolebruken. Dokumentversjon og godkjenninger skal kunne spores.

8. Opphør, tilbakelevering og sletting

Ved opphør skal data etter kommunens valg tilbakeleveres eller slettes, og eksisterende kopier slettes med mindre videre lagring kreves ved lov. Teknisk bekvemmelighet eller «nødvendige logger» er ikke alene en generell hjemmel for videre lagring.

  • • Fjerning fra et Space, kontodeaktivering, arkivering og sletting er ulike handlinger. Tilgang kan stoppes uten at innhold slettes. Sletting må også håndtere vedlegg, referanser, leverandørkopier og eventuelle gamle tilgangslenker; arkivering alene dokumenterer ikke sletting.
  • • Avtaleutkastet foreslår målfrister som må fastsettes med skoleeier: elevarbeid og tilhørende lyd/filer under aktivt undervisningsløp og sletting innen 90 dager etter avtalt avslutning, drifts-/feillogger 30 dager og sikkerhetslogger 90 dager. Skolens instruks, tidligere sletting og tilbakelevering avklares i bilag D. Konkret hendelsesmateriale kan bevares særskilt med dokumentert grunnlag og ny vurderingsdato. Fristene er ikke samlet verifisert håndhevet i drift; rutiner, eksport, kopier og leverandørfrister ferdigstilles separat.

Bilag A – behandlingens innhold

Skoleformålet er lærerstyrt undervisning: dele læringsinnhold, gjennomføre aktiviteter, motta elevarbeid, gi tilbakemelding og administrere skolens bruk. Live inngår i foreslått skoleomfang. KI-hjelp, analyse, publisering, lesetester og egenstudie har egne vurderingspunkter; foreslåtte begrensninger er ikke automatisk teknisk håndhevet.

  • • Registrerte: skolens elever, inkludert elever som deltar med kode, lærere og skoleadministratorer; kontaktpersoner/foresatte der funksjonen og formålet er avklart. Behandling: registrering, autentisering, organisering, lagring, visning, tilbakemelding, eventuell KI-behandling, support og sletting etter instruks.
  • • Datakategorier: konto-/rolle-/romdata, elevtekst og svar, resultater, lærer-/KI-feedback, lyd/podcastsegmenter, bilder, tekniske metadata og relevante logger. Funksjonsomfang, omfang av data, varighet, rettsgrunnlag hos kommunen og eventuelle særkategorier må avgrenses før signering.
  • • Når læreren ber om KI-feedback, kan elevsvar, oppgavetekst, relevant lesetekst, resultater og annen nødvendig oppgavekontekst sendes til OpenAI. At eleven ikke chatter direkte med KI betyr derfor ikke at elevarbeid holdes utenfor KI-behandlingen. Fritekst kan inneholde personopplysninger.
  • • Feide-portalen viser tre attributtgrupper/scopes: navn (userinfo-name), brukeridentifikatorer hos organisasjonen (userid-feide) og e-post (email). Oppgitte formål er gjenkjenning, riktig kontokobling, sikker innlogging, kontoadministrasjon og nødvendig kommunikasjon. Faktisk utlevering avhenger av organisasjonskatalogen og oppsettet. Kontoflyten kan lagre navn og e-post fra Firebase. Eventuell datakildedeling og faktisk feltbruk avstemmes særskilt.

Bilag B – sikkerhet og drift

Tilgangskontroll, privat filflyt og godkjenning av deltakerbindinger ble satt i drift 28. oktober 2026. Firestore-/Storage-regler og appflyt er kontrollert med syntetiske kontoer, et eget testrom og avvisning av uvedkommende tilgang. Gamle direkte downloadtoken er tilbakekalt for hele det kartlagte utvalget på 128 lydfiler, etterkontrollert 29. oktober. Filer, besvarelser og medlemskap er bevart. Skolegrensen for nye invitasjoner ble innført 6. november og tidsbegrenset vikartilgang 7. november 2026, begge med dokumentert funksjonskontroll. Kontrollgrunnlaget gjelder de undersøkte flytene og filutvalget.

  • • Godkjenningsflyten for nye kontotilknytninger i Spaces er innført. Personlig deltakerkode alene gir ikke en ny konto/enhet tilgang til eksisterende deltakerarbeid. En lærer med nødvendig administrasjonstilgang godkjenner tilknytningen med deltakerens midlertidige bekreftelseskode. Tilgang kan tilbakekalles uten at arbeidet slettes. Flyten er kontrollert med syntetiske kontoer og testrom. Kode/QR krever ikke privat e-post, men innebærer ikke at elevdata er anonymisert.
  • • Skolegrensen for nye medlærer- og observatørinvitasjoner til skolerom er innført og kontrollert 6. november 2026. Lærere som inviteres, må ha aktiv tilknytning til samme skole. Skoleadministratorrollen gir ikke i seg selv innsyn i individuelle elevsvar eller rett til å invitere på vegne av romeier.
  • • Tidsbegrenset vikartilgang er innført og kontrollert 7. november 2026. Skoleadministrator kan gi en lærer med aktiv tilknytning til samme skole tilgang til et bestemt skolerom, også ved lærerfravær. Vikaren kan lese oppgaver og elevsvar og gi skriftlig tilbakemelding gjennom en egen avgrenset visning. Tilgangen kan trekkes tilbake og utløper automatisk. Tildeling, utløpsfrist og tilbakekalling loggføres. Tilgangen gir ikke ordinære administrasjonsrettigheter i rommet eller generell tilgang til skolens øvrige rom.
  • • Kontroller med syntetiske kontoer og testrom har bekreftet avvisning over skolegrensen, fortsatt ordinær elev- og medlærertilgang og at tilbakekalling og utløp stenger videre vikartilgang. Eksisterende elevarbeid er bevart. Kontrollgrunnlaget gjelder de prøvde flytene.
  • • Planner er satt på pause i den publiserte løsningen. Navigasjon, direkte sider, Planner-API-er, KI-/kalenderinnganger og vanlig klienttilgang til originalplanene er sperret. Selvstendige oppgavekopier som tidligere er delt til Spaces følger fortsatt ordinær Spaces-tilgang. Pausen sletter eller migrerer ikke eksisterende innhold.
  • • Vercel Functions i produksjon kjører i Frankfurt (fra1), kontrollert ved innføringen 28. oktober 2026. Flyttingen endrer ikke automatisk behandlingssted hos Firebase Authentication, OpenAI, Resend eller øvrige tjenester, og avgrenser heller ikke all logging, CDN-, bygge- og supportbehandling til EØS.
  • • Daglig sikkerhetskopiering er etablert for Firestore, Firebase Authentication-kontoer og ferdig lagrede filer, med lagring i Belgia. Auth- og filkopiene kontrolleres separat. Ved feil eller uteblitt helsekontroll sendes varsel til driftsansvarlig og reserveperson. Første planlagte automatiske Auth-/filrunde ble gjennomført og separat verifisert 4. november 2026. Uferdige filopplastinger inngår ikke i filkopien.
  • • Avgrensede gjenopprettingsprøver for Firestore, filer og Auth-kontoer er gjennomført med syntetiske data i isolerte skymiljøer. Rutinen dokumenterer kontroll av data og tilgang før gjenåpning. Samlet gjenoppretting av en Spaces-fil sammen med tilhørende dokumentreferanser er et eget gjenstående kontrollsteg. Dataimport gjenoppretter ikke nødvendigvis tidligere innloggingsøkter.
  • • Innført tilgangskontroll, privat filflyt, deltakerbinding og backup er beskrevet her. Bilaget skal i tillegg konkretisere drift-/supporttilgang, kryptering, endringsstyring, logger, bruddvarsling og periodisk kontroll, med ansvar og dokumentasjonsgrunnlag.
  • • Ansvar, produksjonsstatus og Fjord Services driftsrutiner skal bekreftes og dokumenteres i bilaget.

Bilag C – leverandører, steder og overføringer

321skole bruker Google Cloud Firestore og Firebase Storage i prosjektet skole-c09b8. Firestore-databasen (default) og Storage-bøtten skole-c09b8.firebasestorage.app ligger begge i europe-west1 (Belgia). Bøtten har regional lagring. Plasseringene er kontrollert av Fjord Service i Firebase Console og Google Cloud Console 18. oktober 2026.

  • • Lagring i en europeisk region betyr ikke at all behandling skjer i EØS. Autentisering, serverbehandling, support, logger, KI og e-post må vurderes hver for seg. Avtalepart, behandlingsland, relevant overføringsgrunnlag og eventuelle tilleggstiltak skal bekreftes per leverandør.
  • • 321school bruker OpenAI Platform/API. Produkteier opplyser at DPA er signert 23. oktober 2026. Kontobilder viser alle tre delingsvalg deaktivert, API call logging Enabled per call og Project Residency Global. OpenAI oppgir at API-data ikke brukes til trening uten aktiv tilslutning. Global er ingen EU-avgrensning eller angivelse av ett bestemt behandlingsland. Svarlagring, Files, prompt-cache og sikkerhetslogger har ulike regler; ingen generell nullagringsgaranti gis. Eksplisitt store:false i de utvalgte tekstkallene er innført 28. oktober 2026. Dette endrer ikke de øvrige lagringsreglene.
  • • Skal fylles per relevant leverandør: juridisk avtalepart, rolle, formål, datatyper, behandlings-/lagringsland, supporttilgang, avtale/dato, overføringsgrunnlag og eventuelle tilleggstiltak. Listen på underleverandørsiden er arbeidsgrunnlag og ikke i seg selv kommunens godkjenning.

Bilag D – oppbevaring og avslutning

Avtaleutkastet foreslår målfrister som må fastsettes med skoleeier: elevarbeid og tilhørende lyd/filer under aktivt undervisningsløp og sletting innen 90 dager etter avtalt avslutning, drifts-/feillogger 30 dager og sikkerhetslogger 90 dager. Skolens instruks, tidligere sletting og tilbakelevering avklares i bilag D. Konkret hendelsesmateriale kan bevares særskilt med dokumentert grunnlag og ny vurderingsdato. Fristene er ikke samlet verifisert håndhevet i drift; rutiner, eksport, kopier og leverandørfrister ferdigstilles separat.

  • • Daglig sikkerhetskopiering er etablert for Firestore, Firebase Authentication-kontoer og ferdig lagrede filer, med lagring i Belgia. Auth- og filkopiene kontrolleres separat. Ved feil eller uteblitt helsekontroll sendes varsel til driftsansvarlig og reserveperson. Første planlagte automatiske Auth-/filrunde ble gjennomført og separat verifisert 4. november 2026. Uferdige filopplastinger inngår ikke i filkopien.
  • • Firestore-kopier har 14 dagers oppbevaring. Auth- og filbackupområdet har en livssyklusregel som gjør kopier kvalifisert for sletting etter 14 dager og sju dagers soft delete etter faktisk sletting. Tidspunktet for sletting avhenger av når livssyklusregelen kjøres. Oppbevaring av sikkerhetskopier er forskjellig fra fristene for elevarbeid og logger i bilag D.
  • • Avgrensede gjenopprettingsprøver for Firestore, filer og Auth-kontoer er gjennomført med syntetiske data i isolerte skymiljøer. Rutinen dokumenterer kontroll av data og tilgang før gjenåpning. Samlet gjenoppretting av en Spaces-fil sammen med tilhørende dokumentreferanser er et eget gjenstående kontrollsteg. Dataimport gjenoppretter ikke nødvendigvis tidligere innloggingsøkter.
  • • Skal fylles per datakategori: frist/kriterium, startpunkt, hvem som instruerer og utfører, eksportformat, tidspunkt for utilgjengeliggjøring og sletting, behandling av sikkerhetskopier/leverandørkopier, lovpålagt videre lagring og bekreftelse til kommunen.