Databehandleravtale

1. Parter

Behandlingsansvarlig: kunden, slik den er angitt i signaturfeltet under punkt 14.

Databehandler: DMZ DATA AS, organisasjonsnummer 983 904 068, forretningsadresse Farmannvegen 20A, 3925 Porsgrunn, Norge. Kontakt: kontor@dmz.no, telefon 35 51 23 22.

Ved motstrid går denne avtalen foran den generelle avtalen om bruk av Vevet i spørsmål om behandling av personopplysninger.

2. Formål og varighet

Formålet er at databehandler skal levere Vevet — planlegging, lagring og visning av innhold på kundens skjermer — og behandle personopplysninger utelukkende for dette formålet, etter behandlingsansvarliges dokumenterte instruks.

Avtalen gjelder fra signering og så lenge databehandler behandler personopplysninger på vegne av behandlingsansvarlig. Den opphører når kundeforholdet avsluttes og data er slettet eller returnert etter punkt 11.

3. Kategorier av registrerte og opplysninger

Kategoriene er beskrevet i Bilag A. Behandlingsansvarlig skal ikke legge inn særlige kategorier av personopplysninger etter art. 9 — herunder helseopplysninger, diagnoser, pasient- eller beboeridentifikasjon, biometriske data og fødselsnummer — eller opplysninger om straffedommer etter art. 10 i Vevet. Tjenesten er ikke laget for slike opplysninger, og hostingleverandørens gjeldende standardvilkår tillater dem heller ikke uten at abonnementet eller en separat avtale uttrykkelig åpner for det.

I helse- og omsorgsbygg skal bruken begrenses til generell drifts- og besøksinformasjon, uten navn, bilde eller romnummer, og uten opplysninger som avslører at en bestemt person mottar helsehjelp. Skal dette åpnes, kreves uttrykkelig kontraktsgrunnlag hos alle relevante leverandører, ny risikovurdering og DPIA, og skriftlig godkjenning fra begge parter før bruk.

4. Databehandlers plikter etter art. 28(3)

1. Instruks. Databehandler behandler personopplysninger kun etter dokumentert instruks fra behandlingsansvarlig, herunder om overføring til tredjeland. Bruk av tjenesten slik den er dokumentert regnes som instruks. Pålegges databehandler en behandling ved lov, varsles behandlingsansvarlig før behandlingen, med mindre loven forbyr det.
2. Taushetsplikt. Alle som får tilgang til personopplysninger hos databehandler er underlagt taushetsplikt, enten ved avtale eller ved lov.
3. Sikkerhet. Databehandler gjennomfører egnede tekniske og organisatoriske tiltak etter art. 32. Tiltakene er beskrevet i Bilag C.
4. Underdatabehandlere. Databehandler bruker underdatabehandlere kun på vilkårene i punkt 5, og pålegger dem de samme forpliktelsene som følger av denne avtalen.
5. Bistand ved henvendelser. Databehandler bistår behandlingsansvarlig med egnede tekniske og organisatoriske tiltak, så langt det er mulig, med å oppfylle plikten til å svare på henvendelser fra registrerte etter art. 12–23.
6. Bistand med sikkerhet, avvik og DPIA. Databehandler bistår behandlingsansvarlig med å oppfylle pliktene etter art. 32–36, herunder varsling av avvik, vurdering av personvernkonsekvenser (DPIA) og forhåndsdrøfting med Datatilsynet.
7. Sletting eller retur. Ved avtalens opphør sletter eller returnerer databehandler alle personopplysninger etter behandlingsansvarliges valg, og sletter eksisterende kopier med mindre lagring er lovpålagt. Se punkt 11.
8. Dokumentasjon og revisjon. Databehandler stiller til rådighet all informasjon som er nødvendig for å vise at pliktene i art. 28 er oppfylt, og muliggjør og bidrar til revisjoner. Se punkt 10.

5. Underdatabehandlere

Behandlingsansvarlig gir med dette generell skriftlig godkjenning til at databehandler bruker underdatabehandlerne som er listet i Bilag B, jf. art. 28 nr. 2.

Ved bytte eller tillegg av underdatabehandler varsles behandlingsansvarlig normalt minst 30 dager i forveien. Behandlingsansvarlig kan innen varselfristen protestere skriftlig på saklig grunnlag. Blir partene ikke enige, kan behandlingsansvarlig si opp den berørte delen av tjenesten uten kostnad, med virkning fra endringen trer i kraft.

Databehandler er fullt ut ansvarlig overfor behandlingsansvarlig for at underdatabehandlerne oppfyller sine forpliktelser.

6. Overføring til tredjeland

Primær lagring og appregion er satt til EU/EØS. Overføring ut av EØS — typisk support, kontrollplan- og bruksmetadata og leverandørtilgang — skjer bare der det fremgår av Bilag B, og da på EUs standard personvernbestemmelser (SCC). Gjeldende DPA/SCC og, der det kreves, en overføringsvurdering (TIA) må dokumenteres før personopplysninger behandles i produksjon. Ingen slik overføringsvurdering er utført ennå; den står som åpent kontrollpunkt for Lovable og Supabase og andre relevante USA-tilganger. Databehandler overfører ikke personopplysninger ut av EØS på eget initiativ ut over dette.

7. Tekniske og organisatoriske tiltak

Tiltakene etter art. 32 er beskrevet i Bilag C. Databehandler kan endre tiltakene, men ikke slik at sikkerhetsnivået samlet sett svekkes.

8. Brudd på personopplysningssikkerheten

Databehandler varsler behandlingsansvarlig uten ugrunnet opphold, og normalt senest innen 24 timer etter at bruddet er bekreftet.

Fristen på 72 timer etter art. 33 er en annen frist, og gjelder ikke databehandlers varsel til kunden: den gjelder behandlingsansvarlig, som selv vurderer om bruddet skal meldes til tilsynsmyndigheten innen 72 timer etter at det ble kjent. Databehandlers varsel innen 24 timer skal gi behandlingsansvarlig tid til den vurderingen.

Varselet beskriver bruddets art, hvilke kategorier og omtrentlig antall registrerte og opplysninger som er berørt, sannsynlige konsekvenser, og hvilke tiltak som er iverksatt eller foreslås. Er ikke alt kjent, sendes opplysningene etter hvert. Databehandler varsler aldri tilsynsmyndighet eller registrerte på egen hånd uten avtale.

9. Bistand ved henvendelser, DPIA og forhåndsdrøfting

Mottar databehandler en henvendelse direkte fra en registrert, videreformidles den til behandlingsansvarlig uten ugrunnet opphold, og databehandler svarer ikke selv på realiteten.

Databehandler bistår med innsyn, retting, sletting, begrensning og dataportabilitet så langt funksjonene i Vevet og databehandlers tilgang tillater det, og stiller dokumentasjon til rådighet for behandlingsansvarliges DPIA og eventuelle forhåndsdrøftinger med Datatilsynet.

10. Revisjon og innsyn

Behandlingsansvarlig kan revidere databehandlers etterlevelse av denne avtalen én gang per år, og ellers ved mistanke om avvik eller etter pålegg fra tilsynsmyndighet. Revisjon varsles normalt 30 dager i forveien og gjennomføres slik at driften forstyrres minst mulig.

Revisjonsretten anses oppfylt ved at databehandler legger frem denne avtalen med bilag, underdatabehandlerlisten og beskrivelsen av tekniske tiltak, sammen med skriftlige svar på spørsmål fra behandlingsansvarlig. Det foreligger ingen ISO 27001-, SOC 2- eller tilsvarende revisjonsrapport for DMZ DATA AS. Behandlingsansvarlig kan likevel kreve fysisk revisjon med rimelig varsel; kostnadene ved revisjon ut over dokumentasjonen over dekkes av behandlingsansvarlig.

11. Opphør, sletting og retur av data

Ved opphør velger behandlingsansvarlig om data skal slettes eller returneres. Valget må meddeles innen 30 dager etter opphør; uten beskjed slettes dataene.

• Eksportformat: strukturerte data leveres som JSON eller CSV, og opplastede filer i sitt opprinnelige format.
• Slettefrist: data databehandler behandler på behandlingsansvarliges vegne slettes fra produksjonsmiljøet innen 30 dager etter opphør eller etter fullført eksport. For sikkerhetskopier oppgir vi ingen fast frist; de rulleres etter den aktive planen hos databaseleverandøren, jf. Bilag C.
• Konto- og kontraktsdata: opplysninger DMZ DATA AS behandler som selvstendig behandlingsansvarlig — kontoopplysninger, kontrakt, kontaktpersoner og korrespondanse — er ikke omfattet av 30-dagersfristen over. De kan oppbevares inntil 90 dager etter opphør for å avslutte og dokumentere kundeforholdet, og regnskapsdata så lenge bokføringsloven krever. De to fristene gjelder altså ulike data og ulike roller.
• Hvordan slettingen skjer: sletting ved avtaleopphør er en dokumentert manuell rutine som utføres av databehandler, ikke en automatisk jobb. Behandlingsansvarlig kan be om skriftlig bekreftelse på at slettingen er gjennomført.
• Løpende sletting underveis: aktivitetslogg, e-postlogg og KI-hendelseslogg slettes automatisk av en planlagt jobb i databasen, vevet_sletterutine, som kjører hver natt klokken 02:15 UTC.
• Personopplysninger vi må beholde etter lov — typisk fakturerings- og regnskapsdata — beholdes bare så lenge loven krever, og bare til det formålet.

12. Ansvar og erstatning

Partene er ansvarlige etter GDPR art. 82 og norsk rett. Databehandler er ansvarlig for skade som skyldes at databehandler har brutt plikter som særskilt påhviler databehandlere, eller har handlet utenfor eller i strid med behandlingsansvarliges lovlige instruks.

Behandlingsansvarlig er ansvarlig for at innholdet som publiseres har et gyldig behandlingsgrunnlag. Ansvarsbegrensninger i den generelle avtalen mellom partene gjelder også her, men begrenser ikke ansvaret overfor registrerte eller tilsynsmyndighet. Er det ikke avtalt en egen ansvarsbegrensning i kundeavtalen, gjelder ansvarsbegrensningen i vilkårene for bruk.

13. Lovvalg og verneting

Avtalen er underlagt norsk rett. Verneting er Telemark tingrett.

14. Signering

Avtalen kan signeres elektronisk eller i to eksemplarer, ett til hver part. Skriv ut siden og fyll ut feltene under. Feltene sender ingen data noe sted.

Bilag A — behandlingens formål, art, omfang og kategorier

Formål: å levere Vevet slik behandlingsansvarlig bruker tjenesten: opprette kontoer og tilganger, lagre og planlegge innhold, og vise innhold på tilkoblede skjermer.

Behandlingens art: innsamling, lagring, strukturering, visning på skjerm, overføring til underdatabehandlere i EU, og sletting.

Omfang: løpende behandling så lenge kundeforholdet varer, begrenset til det behandlingsansvarlig selv legger inn og til driftsdata som er nødvendig for tjenesten.

Kamerabilder: enkelte innholdstyper kan bruke kameraet på skjermen. Bildene behandles kun lokalt i nettleseren på skjermen, sendes aldri til server eller KI-leverandør, og lagres aldri. Kameraet brukes ikke til ansiktsgjenkjenning, publikumsmåling, aldersvurdering eller følelsesgjenkjenning.

Lagringstider

Bilag B — underdatabehandlere

Listen under er den samme som på /underdatabehandlere. Bilaget genereres fra samme leverandørkatalog som den offentlige listen. Det reduserer risikoen for avvik mellom dokumentene. Bilaget omfatter kun leverandører som behandler personopplysninger på våre vegne. Eksterne datakilder og tekniske oppslag — som værvarsel, holdeplasser, nyheter og bildesøk — er ikke underdatabehandlere og står i egen kategori på siden det lenkes til.

Bilag C — tekniske og organisatoriske sikkerhetstiltak

Tiltakene under er de som faktisk er implementert i Vevet eller følger av plattformen vi bruker. Vi beskriver ikke tiltak vi ikke har.

Tilgangskontroll

• Skillet mellom organisasjoner håndheves i databasen med row-level security på alle tabeller, ikke bare i applikasjonen.
• Rollebasert tilgang: superadmin, organisasjonsadministrator, avdelingsansvarlig og bruker med tilgang per avdeling eller kanal. Roller lagres i egen tabell, aldri på brukerprofilen.
• Passord velges av brukeren selv og lagres kun som hash hos innloggingsleverandøren.
• Tofaktorpålogging (MFA) er tilgjengelig for brukerkontoer.
• Skjermer får en egen enhetsnøkkel som ikke gir tilgang til administrasjonen, og en skjerm viser ingenting før den er eksplisitt paret.
• Administrativ tilgang hos databehandler er begrenset til de ansatte i DMZ DATA AS som trenger den for drift og support, og gis per person. Tilgangen fjernes når behovet opphører.

Kryptering og transport

• Trafikk mellom nettleser eller skjerm og Vevet sine egne offentlige adresser bruker HTTPS/TLS. Kundekonfigurerte lokale kameraer kan lastes direkte over HTTP på kundens lokale nettverk; strømmen går ikke via Vevet. Kundestyrt tredjepartsinnhold følger leverandørens transport og personvernvilkår.
• Sikkerhetshoder som HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy og Cross-Origin-Opener-Policy er forberedt i konfigurasjon for en framtidig Vercel-hosting, men er ikke implementert og målt på hostingplattformen som brukes i dag. De oppgis derfor ikke som gjeldende tiltak, men som åpent kontrollpunkt. Content-Security-Policy er ikke innført.
• Data lagres kryptert i ro hos database- og fillagringsleverandøren.
• Nøkler og hemmeligheter ligger som miljøvariabler på serversiden og eksponeres aldri i nettleseren. KI-kall går alltid via vår egen server.

Logging og sporbarhet

• Aktivitetslogg over innlogging, endringer i innhold, skjermer, brukere og tilganger. Oppbevares i 180 dager.
• E-postlogg med mottaker, type, emne, status og tidspunkt — aldri innholdet.
• Logg over stoppede forsøk i KI-hjelpen, med kort tekstutdrag. Oppbevares i 12 måneder.
• Loggene inneholder aldri passord, nøkler eller fullstendig innhold.

Sikkerhetskopi og gjenoppretting

• Databasebackup og retensjon følger den aktive planen hos databaseleverandøren, og verifiseres i driftsprotokollen. Leverandøren dokumenterer selv at daglige sikkerhetskopier og oppbevaringstid varierer med plan, og at objekter i fillageret ikke inngår i databasebackup. Vi oppgir derfor ingen fast frekvens eller retensjonstid her.
• Vi oppgir heller ingen maksimal frist for når en sikkerhetskopi med slettede data er overskrevet, og ingen avtalt RPO eller RTO. Faktisk oppsett er et åpent kontrollpunkt som skal dokumenteres før produksjonsbehandling.

Utvikling og endringshåndtering

• All kode er versjonskontrollert, og endringer i databasen skjer som versjonerte migrasjoner.
• Endringer bygges og typesjekkes automatisk før de settes i produksjon.
• Adskilte miljøer for utvikling/forhåndsvisning og produksjon.
• Endringer godkjennes av utvikleransvarlig i DMZ DATA AS før produksjonssetting. Hostingplattformen kjører et grunnleggende sikkerhetsskann ved publisering. Vi har ingen egen automatisk avhengighetsskanning, og oppgir det heller ikke som et tiltak.

Leverandørstyring

• Alle underdatabehandlere er listet i Bilag B med lokasjon og overføringsgrunnlag.
• Leverandørenes gjeldende databehandleravtaler er lenket i Bilag B. Der aksept eller signering ennå ikke er dokumentert, står det som et åpent kontrollpunkt i bilaget — vi skriver ikke at en avtale er inngått uten dokumentasjon.
• Endringer i leverandørlisten varsles normalt 30 dager i forveien.

Fysisk sikkerhet hos leverandørene

• Vi drifter ikke egne datasentre. Leverandørene ivaretar fysisk sikkerhet. Regioner og overføringsgrunnlag fremgår av Bilag B.
• Sertifiseringer for datasentrene dokumenteres av den enkelte leverandøren i Bilag B. DMZ DATA AS er selv ikke ISO 27001- eller SOC 2-sertifisert.