KLASO Databehandleravtale (B2B + B2G — canonical)

Mellom Sele AS (org.nr 930 950 270) — heretter «Sele» og kunden («Kunden»). Avtalen utgjør et tillegg til Hovedavtalen om bruk av KLASO-plattformen.

Avtalen finnes i to varianter:

• B2B (organisator/skole/tilbyder): standard databehandler-relasjon (GDPR art. 28). Kunden er behandlingsansvarlig; Sele er databehandler.
• B2G (kommune): felles behandlingsansvar (GDPR art. 26) der Sele og kommunen er felles behandlingsansvarlige for institusjonelle behandlinger (skole, SFO, barnehage), supplert med databehandler-relasjon for plattform-drift. Den B2G-spesifikke delen er samlet i § 10. Resterende paragrafer gjelder begge varianter.

1. Definisjoner

I denne avtalen menes:

• Personopplysning: Som definert i GDPR art. 4 nr. 1.
• Behandling: Som definert i GDPR art. 4 nr. 2.
• Den registrerte: Foreldre, foresatte, barn, ungdom, ansatte og elever som registreres i plattformen.
• Behandlingsansvarlig: I B2B-varianten er Kunden behandlingsansvarlig (art. 4 nr. 7). I B2G-varianten er Sele og kommunen felles behandlingsansvarlige.
• Databehandler: Sele når Sele behandler personopplysninger på vegne av Kunden (B2B-variant); ev. plattform-drift-aspekter også i B2G-variant.
• Underleverandør (sub-processor): Tredjepart som behandler personopplysninger på vegne av Sele for å levere KLASO-tjenestene. Liste i § 3.
• Klaso Admin / system_admin: Sele AS sin plattform-, kunde-, support-, sikkerhets- og compliance-rolle. Rollen skal bruke minimerte adminflater og er ikke en generell operativ innsynsflate til Kundens rådata.
• Personvernforordningen / GDPR: Forordning (EU) 2016/679 og personopplysningsloven (LOV-2018-06-15-38).
• SCC: EUs standard kontraktsvilkår for tredjelands-overføring (Kommisjonens gjennomføringsbeslutning (EU) 2021/914).

2. Behandlings-omfang

2.1 Formål og rettslig grunnlag

Sele behandler personopplysninger på vegne av Kunden for følgende formål:

B2B (tilbyder/organisator):

1. Administrasjon av aktivitets-tilbud, deltakerlister, oppmøte-registrering
2. Kommunikasjon mellom tilbyder og foreldre om aktivitet og helseopplysninger
3. Fakturering og betalings-håndtering for aktivitets-deltakelse (via Stripe)
4. Tilbyder-abonnement-administrasjon

B2G (kommune — felles-ansvar, se § 10):

1. Koordinering av henting og levering ved kommunens institusjoner
2. Klassekart og kontaktinformasjon for foresatte ved kommunens skoler
3. Pedagogisk dokumentasjon og skolemiljø-saker (opplæringslova kap. 12, § 12-4)
4. Sikkerhetsrapporter og institusjons-administrasjon
5. Skole-roster-import (OneRoster) og rolle-attestasjon (Feide)

Plattformdrift, support, sikkerhet og compliance (begge varianter): Sele kan behandle nødvendige og begrensede admin-, support-, sikkerhets-, audit-, sanksjons-, datauttrekks- og kundemetadataopplysninger for å levere, sikre, dokumentere og støtte tjenesten. Dette skal normalt skje via minimerte Klaso Admin-flater. Rå eller sensitiv tenant-data, herunder barns rådata, helse-/care-data, meldingsinnhold og nødhendelsesdetaljer/GPS, skal ikke være stående Klaso Admin-standardflate og krever dokumentert support-/compliance- eller break-glass-prosess når innsyn er nødvendig.

2.2 Datakategorier

2.3 Taushetsplikt

Begge parter erkjenner at personopplysninger behandlet under denne avtalen kan være underlagt taushetsplikt etter forvaltningsloven § 13 flg., taushetsbestemmelsene i opplærings- og barnehagesektoren, og barnehageloven § 44 (B2G-relasjoner). Begge parter forplikter seg til å sikre at kun autorisert personell med tjenstlig behov har tilgang.

3. Underleverandører (sub-processors)

Sele benytter følgende underleverandører ved leveranse av KLASO-tjenestene. Cross-link: oppdatert leveranse-state per processor i data-processors.md.

Status-leksikon i tabellen under:

• ✅ Auto-bundlet: DPA-aksept skjer implisitt ved tjeneste-bruk (typisk via Provider's Commercial ToS / Service Agreement).
• ✅ Signert (separat-flow): DPA er manuell-signert i Provider-konsoll eller via egen kontrakt med Sele AS.
• 🟡 Deployd + stub-mode-gated: kode er deployd og live i prod, men returnerer stub-respons inntil flagg-flip (ingen reelle eksterne kall).
• 🔴 DPA pre-launch-blocker: krever signering før live-mode-flip.
• ⏳ DPA pending: under utarbeidelse / venter på provider-respons.

[STATUS-NOTE: jurist-flagg #14 — FREG-flyt (Fase 9, B2G): Skatteetaten/Folkeregisteret (datakilde), Digdir/Maskinporten (autentiserings-fellesløsning) og Buypass (sertifikatutsteder) er ikke ordinære art. 28-underleverandører og står derfor i § 3.3, ikke i tabellen over. Behandlingen er ennå ikke aktivert i drift; leveranse-state spores i data-processors.md.]

3.1 Endring av underleverandører

Sele skal ikke benytte nye underleverandører for behandling av Kundens data uten forhåndsvarsel til Kunden med minimum 30 dagers frist for innsigelse. Dersom Kunden har rimelig grunn til innsigelse, skal partene i god tro forhandle alternativ løsning. Hvis ikke alternativ kan oppnås, har Kunden rett til å si opp avtalen med rimelig oppsigelsesfrist.

Endringer publiseres i versjons-historikken til denne avtalen og varsles eksplisitt til Kunden via e-post.

3.2 Tredjelands-overføring

Personopplysninger lagres i EU/EØS (Supabase eu-central-1 Frankfurt). Følgende underleverandører har komponenter som innebærer tredjelands-overføring under SCC:

• Expo Push Service: USA, mottar push-token + varslingsinnhold (ingen helseopplysninger eller barns persondata)
• Anthropic: USA, mottar pseudonymisert administrativ kontekst-tekst (ingen helseopplysninger eller sluttbrukerdata)
• Sentry: Primært EU; eventuell USA-fallback regulert under SCC
• GitHub: USA, kun kode-hosting (ikke produksjons-data)

Ingen helseopplysninger om barn overføres til land utenfor EU/EØS.

3.3 FREG-flyt (B2G/kommune) — datakilde, autentiserings-fellesløsning og sertifikatutsteder

Status (Fase 9): Gjelder kun B2G-varianten (kommune som Kunde). Aktørene under er ikke ordinære art. 28-underdatabehandlere for Sele — de har distinkte rettslige roller (kolonnen «Kategori»). Behandlingen er ennå ikke aktivert i drift og aktiveres per kommune etter live-gate (se under); leveranse-/kode-state spores i data-processors.md (FREG-flyt-seksjonen). Fullstendig rettsgrunnlag + dataminimering: FREG-databehandler-bilag (kommune), ~/klaso/docs/legal/freg-databehandler-bilag-kommune-draft.md — DRAFT, ikke canonical, jurist/DPO-review pending.

Modell. KLASO henter aldri FREG-opplysninger på egen hånd. Foreldreansvar og foreldre-barn-relasjon er taushetsbelagte etter folkeregisterloven § 10-2 og kan ikke innhentes av en privat aktør uten egen lovhjemmel. Kommunen (skole-/barnehageeier) er behandlingsansvarlig og hjemmelsbærer — opplæringslova § 25-3 m.fl. med forskrift, og barnehageloven § 47/§ 47a med forskrift — søker FREG-tilgang («med hjemmel») i eget navn, og delegerer tilgangen til Sele AS i Altinn. Sele AS er da kommunens databehandler etter GDPR art. 28 for selve FREG-innhentingen, og henter på kommunens vegne under kommunens consumer_org-delegering. Denne databehandler-relasjonen (Sele ↔ kommune) dekkes av denne avtalen + FREG-bilaget; de tre aktørene under er leddene i kjeden, ikke Seles underleverandører i ordinær forstand.

[VERIFISÉR] (jurist): (a) at FREG-innhentingen klassifiseres som art. 28 selv om den øvrige institusjons-behandlingen er art. 26 (§ 10); (b) eksakt hjemmelskjede og ordlyd for opplæringslova § 25-3 + opplæringsforskrifta § 20-1 mot Lovdata, herunder forskriftens hjemmelsgrunnlag (gammel § 15-9 er opphevet; eksakt ordlyd/§-kjede er ikke verifisert her og påstås ikke i noen retning); (c) at adresse ikke er hjemlet under skole-/barnehage-forskriftene (egen hjemmel kreves). Ingen lovtekst er gjengitt ordrett her — se Lovdata-lenker i FREG-bilaget.

Avtale-/autorisasjons-grunnlag. Skatteetatens distribusjonsmodell («Via systemleverandører») fastsetter at en systemleverandør som henter opplysninger på vegne av en konsument blir databehandler for konsumenten, og at det da må foreligge databehandleravtale mellom konsument og systemleverandør — dvs. DPA Sele ↔ kommune (denne avtalen + FREG-bilaget), ikke Sele ↔ Skatteetaten. Disse tre aktørene er ikke art. 28-underdatabehandlere, og § 3.1-prosedyren (underdatabehandler-endring) gjelder dem derfor ikke direkte. Kommunen informeres om FREG-flyten og dens aktører som del av FREG-bilag-signeringen; eventuelle reelle underdatabehandlere som tas i bruk for FREG-flyten (f.eks. ny hosting) varsles på vanlig måte etter § 3.1. [VERIFISÉR] at denne klassifiseringen er korrekt — jf. jurist-flagg #14.

Live-gate. FREG-innhenting aktiveres per kommune først etter (i) signert DPA + FREG-bilag med kommunen, (ii) kommunens FREG-tilgang («med hjemmel») + Altinn-delegering til Sele AS, (iii) Maskinporten-klient + virksomhetssertifikat, (iv) ferdig DPIA med dokumentert art. 35/36-vurdering, (v) bekreftet felt-/rettighetspakke fra Skatteetaten (kun hjemlede felt; adresse utenfor scope inntil egen hjemmel er avklart), (vi) håndtering av adressebeskyttelse (kode 6/7), og (vii) full sikkerhetstest. Leveranse-state spores i data-processors.md.

Kilder. Skatteetaten distribusjonsmodell · folkeregisterloven § 10-2 + § 10-1 · opplæringslova kap. 25 (§ 25-3) · opplæringsforskrifta § 20-1 · forskrift om personopplysninger i barnehagesektoren (FOR-2018-09-28-1479) § 1 (hjemmel barnehageloven § 47/§ 47a) · Digdir — Maskinporten-delegering · FREG-databehandler-bilag-draft §§ 2, 4, 8, 9 · tracking ~/klaso/docs/plans/2026-05-27-fase-9-folkeregisteret-tracking.md.

4. Sikkerhetstiltak

Sele gjennomfører følgende tekniske og organisatoriske tiltak (GDPR art. 32):

Tekniske tiltak:

• Kryptering i transit (TLS 1.2+) og ved rest (AES-256 via AWS-infrastruktur i eu-central-1 Frankfurt)
• Row-Level Security (RLS) på alle databasetabeller
• Relasjonsbasert tilgangskontroll (kun verifiserte foresatte ser barnets data)
• Minimerte Klaso Admin-flater uten stående generell tenant-rådata-tilgang
• Sikkerhets-logging (audit trail) for alle sikkerhetskritiske handlinger
• Automatisk dataminimering (tidsbegrensede snapshots for helseopplysninger)
• Rate limiting på alle API-endepunkter
• MFA-krav for administrative operasjoner
• Sikkerhetsheadere (HSTS, CSP, X-Frame-Options)
• Step-up-mekanikk via BankID/Feide for sensitive operasjoner (deployd; aktiveres ved live-mode-flip av identitets-leverandører)

Organisatoriske tiltak:

• Minste privilegium-prinsippet for tilgang til produksjonsdata
• Dokumentert support-/compliance- eller break-glass-prosess for nødvendig innsyn i rå eller sensitiv tenant-data
• Tofaktor-autentisering på all infrastruktur
• Regelmessig gjennomgang av tilganger
• Utpekt personvernansvarlig (daglig leder)
• Hendelseshåndteringsprosedyre
• ROS-analyse gjennomført

4.1 Konfidensialitet

Begge parter skal sikre at personer autorisert til å behandle personopplysninger har forpliktet seg til konfidensialitet eller er underlagt en passende lovfestet taushetsplikt. Sele har taushetserklæring-mal for eget personell.

5. Brudd på personopplysnings-sikkerheten

5.1 Varsling

Ved brudd på sikkerheten som berører Kundens data, skal Sele varsle Kunden uten ugrunnet opphold og senest innen 24 timer etter at bruddet er oppdaget.

5.2 Innhold i varselet

Varselet skal som minimum inneholde:

• Beskrivelse av bruddet, kategorier og omtrentlig antall berørte
• Kontaktpunkt for ytterligere informasjon
• Sannsynlige konsekvenser
• Tiltak iverksatt eller foreslått for å håndtere bruddet

5.3 Melding til Datatilsynet

Hver part vurderer egen meldeplikt til Datatilsynet (GDPR art. 33, 72-timersfristen) for brudd som berører data innenfor eget ansvarsområde. I B2G-varianten samarbeider partene om informasjonsinnhenting og koordinerer varsling der bruddet berører begges ansvar.

6. Bistand til Kundens etterlevelse

Sele bistår Kunden med:

• Den registrertes rettigheter (art. 12–22): Sele tilrettelegger for innsyn, retting, sletting og portabilitet via plattformens selvbetjente datauttrekk-funksjon. For henvendelser som krever manuell håndtering, svarer Sele innen 30 dager.
• Sikkerhets-vurdering (art. 32): Sele leverer dokumentasjon (sikkerhets-spesifikasjon, ROS-utdrag) på rimelig forespørsel.
• DPIA (art. 35): Sele leverer teknisk informasjon Kunden trenger for egen DPIA av sin bruk av KLASO.
• Forhåndskonsultasjon (art. 36): Ved behov bistår Sele Kunden i Datatilsyns-konsultasjon.

7. Revisjon og kontroll

7.1 Dokumentasjon

Sele gjør på forespørsel tilgjengelig nødvendig dokumentasjon for å påvise etterlevelse av denne avtalen og GDPR art. 28, herunder:

• Teknisk sikkerhets-dokumentasjon
• ROS-analyse-utdrag
• Tilgangs-oversikt
• Hendelses-logg

7.2 Revisjon

Kunden har rett til å gjennomføre eller la en uavhengig tredjepart gjennomføre revisjon av Seles etterlevelse:

• Inntil én gang per år ved planlagt revisjon (30 dagers varsel)
• Ved begrunnet mistanke om brudd (rimelig varsel)

Kostnader for revisjon utover én gang per år eller for utvidet omfang dekkes av Kunden, med mindre revisjonen avdekker vesentlig brudd på denne avtalen — i så tilfelle bæres kostnaden av Sele.

7.3 Sertifisering

Når Sele oppnår ISAE 3402 type II / ISO 27001-sertifisering, kan revisjons-rapporten erstatte individuell revisjon, med mindre Kunden har begrunnet behov for supplerende kontroll.

8. Ansvar og erstatning

Ved kollisjon mellom denne avtalen og Hovedavtalen om KLASO-bruk, skal denne avtalen ha forrang for spørsmål om personopplysninger.

For spørsmål om ansvar og erstatning utover GDPR art. 82 (registrertes erstatnings-rett mot behandlingsansvarlig og databehandler) gjelder Brukervilkårenes ansvars-bestemmelser og eventuell egen hovedavtale med Kunden.

9. Varighet og opphør

9.1 Varighet

Avtalen gjelder så lenge partene behandler personopplysninger gjennom KLASO-plattformen.

9.2 Ved opphør

Ved opphør av avtalen skal Sele etter Kundens valg:

1. Slette alle Kundens data fra plattformen, eller
2. Tilbakelevere data i strukturert maskinlesbart format (JSON-eksport)

Slettingen/tilbakeleveringen gjennomføres innen 90 dager etter opphør. Sele bekrefter skriftlig at sletting er gjennomført.

Merk (B2G): Se § 10.2 for B2C-avgrensning ved kommunens opphør.

9.3 Unntak — anonymisert audit-spor

Audit-trail bevares i anonymisert form (bruker-referanser satt til NULL) i inntil 3 år etter opphør, i samsvar med berettiget interesse for etterrettelighet (GDPR art. 6 nr. 1 f).

10. B2G-spesifikt — felles behandlingsansvar (kun når Kunden er kommune)

Denne paragrafen gjelder kun B2G-varianten (kommunen som Kunde). Den utgjør en avtale om felles behandlingsansvar (GDPR art. 26) som tillegg til den øvrige databehandler-strukturen.

10.1 Felles formål

Partene behandler personopplysninger i fellesskap for følgende formål:

1. Koordinering av henting og levering av barn ved kommunens institusjoner
2. Klassekart og kontaktinformasjon for foresatte ved kommunens skoler
3. Kommunikasjon mellom foresatte og kommunens institusjoner
4. Administrering av institusjoner via kommunens admin-portal og kundens egne administratorer
5. Sikkerhetsrapporter og tilsyn

Klaso Admin-tilgang fra Sele AS til B2G-data er avgrenset til plattformdrift, support, sikkerhet, compliance og rettighets-/avvikshåndtering etter § 2.1 og § 4, og skal ikke forstås som en generell operativ innsynsflate til kommunens barne-, elev-, helse-/care-, meldings- eller nødhendelsesdata.

10.2 Avgrensning — B2C-funksjoner utenfor felles-ansvar

KLASO tilbyr funksjoner der Sele er selvstendig behandlingsansvarlig og kommunen ikke er part. Disse er ikke dekket av felles-ansvar-paragrafen:

• Bursdagsinvitasjoner og private arrangementer
• Fritidsaktiviteter (påmelding hos eksterne tilbydere)
• Ungdomsbarnepass (privat mellom familier og ungdommer)
• Ungdoms nødhjelp-funksjon (GPS-lokasjon til foresatte)
• Senior-tjenesten (kommende — separat ansvarsmodell publiseres ved aktivering)

For disse behandlingene gjelder Seles personvernerklæring (privacy.md).

10.3 Ansvarsfordeling

10.4 Kontaktpunkt for registrerte (art. 26 nr. 1)

Registrerte (foresatte, barn, ansatte) kan henvende seg til begge parter uavhengig av ansvarsfordelingen. Partene videresender uten ugrunnet opphold henvendelser som tilhører den andre parts ansvarsområde.

• Foreldre/barn: personvern@myklaso.app (Sele)
• Kommunens ansatte: kommunens DPO (utfylles ved signering)

10.5 Audit-rett (utvidet)

I tillegg til § 7.2 gjelder kommunens revisjonsrett som forvaltnings-aktør. Sele skal være tilgjengelig for kommunalt tilsyn etter rimelig varsel.

11. Endringer og tvister

11.1 Endringer

Endringer i denne avtalens hovedtekst skal være skriftlige og signert av begge parter. Sele kan oppdatere avtalens tekniske vedlegg (sikkerhets-spesifikasjon, sub-processor-liste i § 3) i samsvar med varslings-prosedyren i § 3.1, under forutsetning av at endringene ikke svekker den registrertes vern.

11.2 Tvister

Tvister søkes løst gjennom forhandlinger. Dersom forhandlinger ikke fører frem, kan tvisten bringes inn for de ordinære domstoler.

12. Signatur

Vedlegg A: Teknisk sikkerhetsbeskrivelse

A.1 Infrastruktur

• Database: PostgreSQL via Supabase, hostet i AWS eu-central-1 (Frankfurt, Tyskland)
• API: PostgREST med Row-Level Security (RLS)
• Web: Vercel (Pro-tier — global CDN; logs i EU)
• Mobil-distribusjon: Expo (EAS Build/Submit)
• Push: Expo Push Service (USA, DPF-sertifisert)
• Email: Mailgun EU (api.eu.mailgun.net, region-låst)
• Autentisering: Supabase Auth + BankID via Idura/Criipto (eIDAS «høyt»); Feide via Sikt/Dataporten for skole-kontekst
• Error-tracking: Sentry (EU-region primært)
• AI-assistert utkast (administrativt): Anthropic Claude (server-side, pseudonymisert kontekst)

A.2 Tilgangskontroll

• 113+ RLS-policyer håndhever tilgangsregler på databasenivå
• Rollebasert tilgang: parent, staff, admin, system_admin/Klaso Admin, provider, youth
• system_admin/Klaso Admin er begrenset til minimerte plattform-, kunde-, support-, sikkerhets- og complianceflater; rå/sensitiv tenant-data krever dokumentert support-/compliance- eller break-glass-prosess
• Relasjonsbasert tilgang via child_guardians (kun verifiserte foresatte)
• «Nei trumfer ja»-prinsipp for samtykke ved delt omsorg
• MFA-krav (TOTP) for system_admin-operasjoner
• Step-up-mekanikk via BankID/Feide for sensitive operasjoner (deployd; aktiveres ved live-mode-flip)

A.3 Kryptering

• Transit: TLS 1.2+ på alle endepunkter
• Ro: AES-256 via AWS (eu-central-1 Frankfurt)
• Personnummer: Kryptert lagring i profiles-tabellen (felt-kryptering via Supabase Vault planlagt)
• Sesjon: iOS Keychain / Android Keystore

A.4 Auto-sletting (lagrings-tider relevant for B2B/B2G-relasjon)

A.5 Hendelses-håndtering

• Automatisk sikkerhets-logging (audit trail) for kritiske hendelser
• 24-timers varslings-plikt til Kunden ved brudd
• Hendelses-håndteringsprosedyre etablert; oppdateres løpende

Denne avtalen er utarbeidet for å møte kravene i GDPR art. 28 (databehandler-relasjon), art. 26 (felles-ansvar i B2G-variant), og Datatilsynets veiledning. Sele AS er ikke juridisk rådgiver — Kunden bør kvalitets-sikre avtalen med egen DPO eller juridisk avdeling, særlig for kommune-relasjoner.