Tilgangskontroll

Hver organisasjon er en egen tenant. Skillet mellom organisasjoner håndheves i databasen med Row-Level Security (RLS) i PostgreSQL, ikke bare i applikasjonskoden: alle tabeller med kundedata har RLS slått på og politikker som knytter hver rad til organisasjonen den tilhører. En spørring som forsøker å lese en annen organisasjons rader, får ingen treff — også om feilen skulle ligge i appen.

• Roller: superadmin (vårt eget team), organisasjonsadministrator, avdelingsansvarlig, bruker med tilgang per avdeling eller kanal, og en enkel ekstern rolle som bare kan legge inn innhold.
• Avdelingstilgang: redaktørrettigheter kan begrenses til bestemte avdelinger og kanaler.
• Aktivitetslogg: handlinger logges. Vanlige brukere har bare leserett til loggen — det er ikke gitt rettigheter til å endre eller slette rader i den. Loggen ryddes automatisk etter 180 dager.
• Skjermer: en skjerm viser ingenting før den er paret med en kort, tidsbegrenset kode og tildelt en kanal. Skjermer kan kobles fra igjen.

Sletterutiner

Jobben vevet_sletterutine kjører hver natt klokken 02:15 UTC i databasen, ikke i applikasjonen. Den virker derfor selv om ingen er innlogget og selv om nettsiden skulle være nede. Kunden kan be om dokumentasjon på gjennomført sletting.

Teknisk beskyttelse

• Transport: trafikk mellom nettleser eller skjerm og Vevet sine egne offentlige adresser bruker HTTPS/TLS. TLS-terminering leveres av hostingplattformen; HSTS er ikke verifisert i aktiv drift, se åpne kontrollpunkter. 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.
• Kryptering ved lagring: database og filer krypteres av leverandøren (Supabase, EU-region). Vi krypterer ikke i tillegg på feltnivå.
• Sikkerhetsheadere: sikkerhetsheadere på aktiv Lovable Cloud-hosting er ikke verifisert. Dette står som et åpent kontrollpunkt, se listen nederst. Content-Security-Policy er ennå ikke innført, og vi setter bevisst ikke X-Frame-Options eller frame-ancestors, fordi tjenesten skal kunne vises i ramme i godkjente sammenhenger.
• Sikkerhetskopi: databasebackup og retensjon følger den aktive planen hos databaseleverandøren, og verifiseres i driftsprotokollen. Leverandøren dokumenterer selv at frekvens og oppbevaringstid varierer med plan, og at objekter i fillageret ikke inngår i databasebackup. Vi oppgir derfor ingen fast frekvens, ingen maksimal slettetid og ingen avtalt RPO eller RTO. Dette er et åpent kontrollpunkt, se listen nederst.
• Cookie-flagg: enhetstokenet til en skjerm lagres i en cookie med httpOnly, sameSite=lax og secure på HTTPS. Innloggingsøkter håndteres av autentiseringsleverandøren.
• Hemmeligheter: API-nøkler og servernøkler ligger som miljøvariabler i plattformens hemmelighetslager, aldri i kildekoden og aldri i nettleseren. Nøkkelen til KI-leverandøren brukes kun av serverkoden.
• Indeksering: visningsmodus og innloggede sider er merket «noindex, nofollow», og robots.txt sperrer visningssiden.

Bruk av kunstig intelligens

• Leverandør og region: kun Mistral AI SAS, mot EU-endepunktet api.eu.mistral.ai, som etter leverandørens dokumentasjon kjører i EU/EFTA-region. Ingen andre KI-leverandører er koblet til.
• Alltid server-side: nettleseren kaller aldri KI-leverandøren direkte.
• Kan slås av: KI-hjelpen kan strupes med kvoter per organisasjon og per bruker, og settes kvoten til null, brukes den ikke. Uten API-nøkkel er funksjonene helt av. Det finnes ingen bakgrunnsbruk av KI: hjelpen kjører bare når en bruker selv trykker.
• Ingen modelltrening: ved ordinær API-bruk brukes data fra Vevet ikke til å trene modeller, og inferensen skjer på EU-endepunktet api.eu.mistral.ai i EU/EFTA-region. Oppbevaringstiden hos leverandøren styres av kontoens personverninnstillinger og avtale, ikke av en fast periode vi kan garantere. Null retensjon (ZDR) er en separat kontroll som må være aktivert og dokumentert før vi kan påberope den. EU-endepunktet styrer inferenssted, men ikke nødvendigvis all kontrollplan- og bruksmetadata.
• Moderering: tekst inn og ut går gjennom både enkle regler i koden og Mistral sitt modereringsendepunkt i EU. Bilder sendes aldri til KI, og kamerabilder aldri.
• Hva som logges: vi logger stoppede forsøk (tidspunkt, bruker, kategori) i 12 måneder, samt antall kall for kvoteformål. Vi lagrer ikke fulltekst av alt som sendes til KI som en egen historikk.

Innhold på skjerm og bilder av personer

Dette er den reelle personvernrisikoen ved digital skjermvisning: skjermen er en offentlig synlig flate i et fysisk rom. Alle i rommet ser innholdet, uansett hvilke tilganger de har, og de kan fotografere det. Tilgangsstyring i verktøyet løser ikke dette — innholdsvalg og plassering gjør det.

Det Vevet gir kunden av virkemidler:

• Tidsstyring per innhold: start, slutt, ukedager og klokkeslett.
• Tilgang per avdeling og kanal, slik at bare de rette kan publisere til en gitt skjerm.
• Egen ekstern rolle som kan levere innhold uten å styre skjermer.
• Bursdagsvisning som kan begrenses til fornavn og til utvalgte skjermer.
• Aktivitetslogg som viser hvem som publiserte hva og når.
• Alt-tekst på bilder, med KI-forslag, for lesbarhet og dokumentasjon.
• Et utgangspunkt for virksomhetens DPIA på /dpia, med risikotabell og forslag til publiseringsregler.

Datalokasjon

Full oversikt med datatyper, overføringsgrunnlag og lenke til leverandørens egen databehandleravtale: /underdatabehandlere (også som JSON).

Lagringstider

Kamera

Kamerainnhold («Vindu» og «Speil») behandles lokalt på skjermen. Bildet vises i sanntid og lastes aldri opp, lagres aldri og tas aldri opp. Det gjøres ingen ansiktsgjenkjenning, ingen telling av personer og ingen bildeanalyse — kamerabilde sendes aldri til KI-leverandøren eller til andre tjenester. Et kameraikon er alltid synlig når en kameratype vises.

Status for ekstern testing og sertifisering

Status per i dag:

• Ekstern penetrasjonstest: ikke gjennomført. Ingen tredjepart har sikkerhetstestet løsningen.
• ISO 27001: ikke sertifisert.
• SOC 2: ikke sertifisert, ingen Type I eller Type II-rapport.
• Formell WCAG-revisjon: ikke gjennomført. Se tilgjengelighetserklæringen.
• Bug bounty-program: finnes ikke. Vi tar likevel imot rapporter, se under.

Det vi faktisk har gjort:

• Tenant-isolasjon håndhevet i databasen med RLS, ikke bare i koden, og rettigheter gitt eksplisitt per tabell.
• Faste sikkerhetsgjennomganger av koden ved endringer i tilgang og datamodell. Hostingplattformen kjører i tillegg et grunnleggende sikkerhetsskann ved publisering. Vi har ingen egen automatisk avhengighetsskanning, og oppgir det derfor ikke som et tiltak.
• Misbruksvern og moderering rundt KI-hjelpen, med logging av stoppede forsøk.
• Kvoter som begrenser skadeomfang ved misbruk av KI og e-post.

Det er ikke fastsatt tidspunkt for ekstern penetrasjonstest eller sertifisering.

Kontaktpunkt og personvernombud

DMZ DATA AS, organisasjonsnummer 983 904 068, Farmannvegen 20A, 3925 Porsgrunn, Norge. Telefon 35 51 23 22. Registrert i Foretaksregisteret og Merverdiavgiftsregisteret.

DMZ DATA AS har ikke plikt til å oppnevne personvernombud etter GDPR art. 37, og har ikke oppnevnt et eget ombud. Kontaktpunktet for personvern og sikkerhet er kontor@dmz.no.

Rapportere en sårbarhet

Vi følger RFC 9116 og publiserer kontaktinformasjon på /.well-known/security.txt. Send funn dit, med nok detaljer til at vi kan gjenskape problemet.

Vi bekrefter mottak og følger opp rapporter som er sendt i god tro, uten tilgang til andres data og uten forstyrrelse av tjenesten. Vi ber om at funn ikke offentliggjøres før vi har rettet dem.

Sjekkliste for anskaffelse

Spørsmålene under er dem kommuner og offentlige virksomheter faktisk stiller. Kolonnen til høyre lenker rett til kapittelet som dokumenterer svaret.

Åpne kontrollpunkter

Dokumentasjonen ble sist kontrollert mot faktisk implementasjon 5. september 2026. Punktene under er ikke gjennomført. De står her fordi vi heller vil vise dem enn å påstå noe vi ikke kan dokumentere, og de skal lukkes før personopplysninger behandles i produksjon.

Alt samlet på én utskriftsvennlig side: /for-personvernombud/utskrift.

1. Behandlingsansvarlig og kontakt

Vevet leveres av DMZ DATA AS, organisasjonsnummer 983 904 068, forretningsadresse Farmannvegen 20A, 3925 Porsgrunn, Norge. Registrert i Foretaksregisteret og Merverdiavgiftsregisteret. Telefon 35 51 23 22, nettsted www.dmz.no. Kontakt i personvernsaker: kontor@dmz.no.

DMZ DATA AS har ikke plikt til å oppnevne personvernombud etter GDPR art. 37, og har ikke oppnevnt et eget ombud. kontor@dmz.no er kontaktpunktet i personvern- og sikkerhetssaker. Henvendelser besvares normalt innen 30 dager, jf. GDPR art. 12 nr. 3.

2. Når vi er behandlingsansvarlig og når vi er databehandler

Vi er behandlingsansvarlig for brukerkontoer, fakturerings- og kundeopplysninger, driftslogger og sikkerhetslogger. For dette er denne erklæringen den gjeldende informasjonen etter GDPR art. 13.

Vi er databehandler for alt innhold kunden selv legger inn i Innholdsbiblioteket, kanaler og Mine filer. Da er organisasjonen behandlingsansvarlig, og behandlingen styres av databehandleravtalen mellom oss.

3. Behandlingsgrunnlag

• Art. 6.1.b — avtale: å levere tjenesten til den som har bestilt den, herunder å opprette kontoer, vise innhold på skjermer og sende driftsrelatert e-post.
• Art. 6.1.c — rettslig forpliktelse: regnskaps- og bokføringsplikt, og plikten til å ha tilfredsstillende informasjonssikkerhet.
• Art. 6.1.f — berettiget interesse: sikkerhets- og aktivitetslogger, misbruksvern for KI-hjelpen og feilsøking. Behandlingen forutsetter en dokumentert interesseavveiing. Den er ennå ikke skrevet, og står som åpent kontrollpunkt på /for-personvernombud.

Der kunden publiserer bilder eller navn på identifiserbare personer, er det organisasjonen som må ha et eget grunnlag — se kapittel 5.

4. Hvilke personopplysninger vi behandler

5. Innhold på skjerm: bilder og navn av personer

Organisasjonen er behandlingsansvarlig for alt den publiserer på skjerm. Bilder av identifiserbare personer krever et eget behandlingsgrunnlag, og i praksis ofte samtykke. Samtykke må være frivillig, spesifikt og mulig å trekke tilbake.

Når innhold gjelder barn, må behandlingsansvarlig vurdere behandlingsgrunnlag og hvem som kan samtykke. For publisering av bilder av mindreårige vil samtykke fra foresatte normalt være nødvendig. For bursdagslister og lignende anbefaler vi at den enkelte selv får velge om navnet skal vises.

Vevet analyserer ikke bilder for å gjenkjenne personer, og lager ingen biometriske profiler.

6. Skjermer og visningsmodus

En fysisk skjerm kobles til med en kort, tidsbegrenset parringskode som en administrator oppretter i Vevet. Skjermen får da en tilfeldig enhetsnøkkel som lagres lokalt i nettleseren på skjermen. Nøkkelen og skjerm-token inneholder ingen personopplysninger, og kan ikke brukes til å logge inn i administrasjonen.

Visningen krever ingen innlogget bruker, og visningssiden er merket slik at søkemotorer ikke indekserer den. En skjerm viser ikke innhold før den er eksplisitt paret og tildelt en kanal.

7. Kamera på skjermen

Enkelte innhold kan bruke kameraet på selve skjermen. Kamerabildene behandles kun lokalt i nettleseren på skjermen. De sendes aldri til noen server, aldri til KI-leverandøren vår, og lagres aldri.

Kameraet brukes ikke til ansiktsgjenkjenning, publikumsmåling, aldersvurdering eller følelsesgjenkjenning. Følelsesgjenkjenning på arbeidsplass og i utdanning er dessuten forbudt etter EU AI Act art. 5, og vi tilbyr ikke slik funksjonalitet.

8. Bruk av kunstig intelligens og EU AI Act

KI-hjelpen kan forbedre, korrekturlese og forkorte tekst, foreslå farger og temaer, og lage korte bildebeskrivelser (alt-tekst). Alle kall skjer fra vår server — aldri fra nettleseren — og nøkkelen ligger som hemmelig miljøvariabel.

Leverandøren er Mistral AI SAS. Vi kaller leverandørens EU-endepunkt api.eu.mistral.ai, som etter leverandørens dokumentasjon kjører i EU/EFTA-region, og modellene som brukes er mistral-medium-latest og mistral-small-latest. Ved ordinær API-bruk brukes innsendte data ikke til å trene modeller. Hvor lenge leverandøren oppbevarer dem, styres av personverninnstillingene og avtalen for kontoen vår — vi oppgir derfor ingen fast periode. Null retensjon (ZDR) er en egen kontroll hos leverandøren som må være aktivert og dokumentert før vi kan påberope den. EU-endepunktet styrer hvor selve behandlingen skjer, men ikke nødvendigvis all kontrollplan- og bruksmetadata.

• Transparens (art. 50): alt KI-hjelpen lager er tydelig merket i grensesnittet som forslag laget med kunstig intelligens.
• Menneskelig kontroll (art. 14): ingenting publiseres automatisk. Et menneske må godta forslaget før det havner på skjerm.
• KI-kompetanse (art. 4): vi beskriver hva verktøyet kan og ikke kan, og bistår kunden med opplæringsmateriell på forespørsel.
• Kan slås av: KI-hjelpen kan deaktiveres per organisasjon. Resten av tjenesten virker som før.

9. Eksterne datakilder

Skjermene kan vise vær, holdeplasser, nyheter, strømpris og lignende. Slike oppslag går alltid fra vår server, aldri fra nettleseren eller skjermen, og de inneholder ingen personopplysninger fra oss. Til værvarsel sender vi avrundede koordinater, til holdeplasser koordinater eller stopp-ID, til strømpris dato og prissone. Det samme gjelder bildesøk: søkeordet sendes til Pixabay GmbH fra vår server, søket knyttes ikke til brukerkontoen, og velger brukeren et bilde kopieres filen til vårt eget lager i EU. Tjenester som dette er ikke underdatabehandlere, fordi de ikke behandler personopplysninger på våre vegne. Hele oversikten står på /underdatabehandlere.

Velger kunden selv å vise en video fra YouTube eller Vimeo, eller en ekstern nettside i en ramme, lastes innholdet direkte fra skjermens nettleser. Leverandøren kan da motta skjermens offentlige IP-adresse og nettlesertype, og kan sette egne informasjonskapsler. At Vevet ikke sporer, gjelder oss — ikke tredjepartsinnhold kunden velger å vise.

10. Lagringstid og automatisk sletting

Aktivitetsloggen, e-postloggen og KI-hendelsesloggen slettes av en planlagt jobb i databasen, vevet_sletterutine, som kjører hver natt klokken 02:15 UTC og fjerner alle rader som er eldre enn grensene i tabellen. Jobben ligger i databasen og ikke i applikasjonen, så den kjører selv om ingen er innlogget.

Ved avtaleopphør skiller vi mellom to roller, og de to fristene er derfor ikke i motstrid:

• Innhold og data vi behandler som databehandler for kunden — innhold, kanaler, filer i Mine filer, skjermer og brukere i kundens organisasjon — slettes eller returneres innen 30 dager etter opphør.
• Konto-, kontrakts- og kontaktdata som vi behandler som selvstendig behandlingsansvarlig kan oppbevares inntil 90 dager for å avslutte kundeforholdet og dokumentere det. Regnskapsdata oppbevares så lenge bokføringsloven krever.

Dette er en dokumentert manuell rutine vi utfører ved avtaleopphør — ikke en automatisk jobb. Kunden kan be om skriftlig bekreftelse på at slettingen er gjennomført. Sikkerhetskopier hos databaseleverandøren rulleres etter den aktive planen der; vi oppgir ingen fast maksimal slettetid for backup, fordi vi ikke kan dokumentere den.

11. Lagringssted og overføring ut av EØS

Primær lagring og appregion er satt til EU/Europa: databasen og filene ligger i en EU-region, og hostingplattformens datalagringsregion er satt til Europe. Vi lover ikke en bestemt by, og vi skriver ikke at behandling og support aldri kan skje utenfor EØS. Der en leverandør kan ha tilgang fra USA — typisk support, kontrollplan- og bruksmetadata og driftslogger — skjer det på EUs standard personvernbestemmelser (SCC). Gjeldende DPA/SCC og, der det kreves, en overføringsvurdering må dokumenteres før produksjon; ingen slik vurdering er utført ennå. Detaljene per leverandør står i underdatabehandlerlisten.

12. Databehandlere og underleverandører

Vi bruker et lite antall underdatabehandlere. Hver av dem er listet med formål, type data, lokasjon, overføringsgrunnlag og lenke til databehandleravtale på /underdatabehandlere. Endringer varsles normalt minst 30 dager i forveien.

Betaling og regnskap står i en egen kategori. Betalingsløsningene er selvstendig behandlingsansvarlige for betalingen, ikke underdatabehandlere for oss, fordi de har egne plikter etter finans- og hvitvaskingsregelverket. Kortopplysninger tastes inn hos betalingsløsningen og lagres aldri i Vevet. Vi lagrer bare referansen til kunden og abonnementet hos leverandøren, samt status på betalingen. Mottakerne er listet under punkt D på /underdatabehandlere.

13. Informasjonskapsler og lokal lagring

Vevet setter ikke egne analyse-, markedsførings- eller sporingskapsler. Lagringen som er listet nedenfor, brukes for innlogging og drift. Kundestyrt tredjepartsinnhold kan bruke egne informasjonskapsler.

Ingen av nøklene over deles med tredjepart.

14. Sikkerhet

• Trafikk mellom nettleser eller skjerm og Vevet sine egne tjenester bruker HTTPS/TLS, og data lagres kryptert hos leverandøren. 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 egen transport og personvernvilkår.
• Skillet mellom organisasjoner håndheves i databasen med row-level security, ikke bare i applikasjonen. Row-Level Security er konfigurert for å hindre at en organisasjon får tilgang til en annen organisasjons data.
• Passord velges alltid av deg selv, lagres kun som hash, og sendes aldri på e-post.
• Tilgang styres av roller, og en bruker ser bare avdelingene den er tildelt.
• Nøkler og hemmeligheter ligger som miljøvariabler på serversiden, aldri i nettleseren.
• Sikkerhetshenvendelser kan meldes etter oppskriften i /.well-known/security.txt.

Vevet sine egne offentlige adresser betjenes over HTTPS/TLS. Et sett med sikkerhetshoder — Strict-Transport-Security, 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 vi kjører på i dag. Vi oppgir dem derfor ikke som verifiserte konkrete verdier eller som satt på alle ruter. Dette står som åpent kontrollpunkt på /for-personvernombud.

Content-Security-Policy er ennå ikke innført. Det står på listen over tiltak, og vi skriver det heller enn å påstå noe annet. Vi setter bevisst ikke X-Frame-Options eller frame-ancestors, fordi tjenesten skal kunne vises i ramme i godkjente sammenhenger.

15. Misbruksvern og innholdsmoderering

Alt som sendes til KI-hjelpen sjekkes før det sendes videre, og svaret sjekkes før du ser det. Regelkontrollen skjer i Vevet sin serverkode. Kall til Mistrals moderering sendes til leverandørens EU-endepunkt. Ulovlig innhold og forsøk på misbruk stoppes og logges med et kort tekstutdrag — aldri hele teksten, og aldri bilder. Gjentatt misbruk kan føre til at KI-hjelpen settes på pause for kontoen en periode.

16. Dine rettigheter

Etter GDPR art. 15–22 kan du, når vilkårene i den enkelte bestemmelsen er oppfylt, be om å:

• få innsyn i opplysningene vi har om deg (art. 15),
• få rettet feil (art. 16),
• få slettet opplysninger (art. 17),
• be om begrensning av behandlingen (art. 18),
• få opplysningene utlevert i et maskinlesbart format (art. 20),
• protestere mot behandling basert på berettiget interesse (art. 21),
• ikke bli utsatt for helautomatiserte avgjørelser (art. 22) — Vevet tar ingen slike avgjørelser.

Hvilke rettigheter som gjelder, avhenger av den konkrete behandlingen og behandlingsgrunnlaget.

Du kan bruke rettighetene direkte i appen under Min side, eller ved å kontakte kontor@dmz.no. Er du ansatt hos en kunde, kan vi måtte henvise deg til arbeidsgiveren din, som er behandlingsansvarlig for innholdet.

17. Bruk i offentlig sektor, skoler og helsebygg

Vevet er laget for informasjon på fellesarealer, og skal som standard ikke brukes til helseopplysninger, diagnoser, pasient- eller beboeridentifikasjon, biometriske data, fødselsnummer eller andre særlige kategorier etter GDPR art. 9. Hostingleverandørens gjeldende standardvilkår åpner heller ikke for slike opplysninger uten at abonnementet eller en separat avtale uttrykkelig tillater det.

Bruk i helse- og omsorgsbygg må 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 noen gang åpnes, kreves uttrykkelig kontraktsgrunnlag hos alle relevante leverandører, ny risikovurdering og DPIA, og skriftlig godkjenning før bruk.

Vi bistår med underlag til virksomhetens egen risikovurdering og eventuell DPIA etter art. 35. Kunder som bruker Vevet til behandling av personopplysninger på egne vegne, skal inngå databehandleravtale før slik bruk.

18. Avvik og varsling

Ved brudd på personopplysningssikkerheten varsler vi berørte kunder uten ugrunnet opphold, og normalt senest innen 24 timer etter at bruddet er bekreftet. Varselet beskriver hva som skjedde, hvilke data det gjelder, sannsynlige konsekvenser og hvilke tiltak vi har satt i verk.

Fristen på 72 timer i GDPR art. 33 er en annen frist: den gjelder organisasjonen som behandlingsansvarlig, som selv vurderer om bruddet skal meldes til Datatilsynet innen 72 timer etter at det ble kjent. Vårt varsel kommer tidlig nettopp for at kunden skal rekke den vurderingen.

19. Klage til Datatilsynet

Mener du at vi behandler personopplysninger i strid med regelverket, kan du klage til Datatilsynet: datatilsynet.no. Vi setter pris på å få høre fra deg først, så vi kan rette opp raskt.

20. Endringer i erklæringen

Vi oppdaterer erklæringen når tjenesten endrer seg. Versjon og dato står øverst på siden. Vesentlige endringer varsles til kundens administratorer, normalt minst 30 dager før de trer i kraft.

Se også vilkårene for bruk.

Se også prisene, personvern og databehandling og databehandleravtalen.

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.

A. Underdatabehandlere som behandler personopplysninger på våre vegne

B. Eksterne datakilder og tekniske oppslag

Disse tjenestene behandler normalt ikke personopplysninger på våre vegne, og er derfor ikke underdatabehandlere. Alle kallene skjer fra vår server, ikke fra nettleseren eller skjermen.

C. Kundestyrte tredjepartstilkoblinger

Kunden velger selv om disse tas i bruk, og er behandlingsansvarlig for det som da skjer.

D. Mottakere for konto, betaling og regnskap

Disse ser aldri innholdet kunden viser på skjerm. De behandler opplysninger om selve kundeforholdet: hvem som kjøper, hva som er kjøpt og at det er betalt. Betalingsmottakerne er selvstendig behandlingsansvarlige etter eget finans- og hvitvaskingsregelverk, og er derfor ikke underdatabehandlere for oss.

Kontraktskontroll før produksjon

Punktene under er åpne. De er ikke gjennomført, og skal være dokumentert før personopplysninger behandles i produksjon.

Se også personvernerklæringen.

Del 1 — der DMZ DATA AS er behandlingsansvarlig

Del 2 — der DMZ DATA AS er databehandler for kunden

For disse behandlingene er organisasjonen behandlingsansvarlig, og vi behandler kun etter dokumentert instruks i databehandleravtalen.

Overføringer ut av EØS

Primær lagring og appregion er satt til EU/Europa. Database, filer, e-post og KI-hjelp ligger hos leverandører i EU/EØS, og hostingplattformens datalagringsregion er satt til Europe. Vi lover ikke en bestemt by, og vi utelukker ikke at en leverandør kan ha tilgang fra USA — typisk support, kontrollplan- og bruksmetadata og tekniske driftslogger. Der det skjer, skjer det på EUs standard personvernbestemmelser (SCC). Gjeldende DPA/SCC og, der det kreves, en overføringsvurdering må dokumenteres før produksjon; ingen slik vurdering er utført ennå. Leverandør for leverandør står dette i underdatabehandlerlisten.

Rettigheter etter art. 15–22

Aktivitetsloggen, e-postloggen og KI-hendelsesloggen slettes automatisk av en planlagt jobb i databasen, vevet_sletterutine, som kjører hver natt klokken 02:15 UTC. Sletting av brukerkontoer og kundeinnhold ved avtaleopphør, og kontroll av at sikkerhetskopier er overskrevet, er en dokumentert manuell rutine som utføres av oss — ikke en automatisk jobb. Kunden kan be om skriftlig bekreftelse på at slettingen er gjennomført.

Registrerte har rett til innsyn, retting, sletting, begrensning, dataportabilitet og til å protestere mot behandling basert på berettiget interesse.

• Er du avbildet eller omtalt på en skjerm, eller ansatt/elev/besøkende hos en av våre kunder, henvender du deg til organisasjonen som eier skjermen. De er behandlingsansvarlig for innholdet. Vi bistår kunden med å svare, jf. art. 28(3)(e).
• Gjelder det din egen brukerkonto i Vevet, henvender du deg til oss på kontor@dmz.no. Mye kan du også gjøre selv under Min side.

Fullstendig protokoll utleveres til tilsynsmyndigheter på forespørsel, jf. art. 30 nr. 4, og til kunder med signert databehandleravtale.

Del 1 — beskrivelse av behandlingen

Bruksområde A: skole og oppvekst

Skjermer i fellesarealer, ganger, kantine, personalrom og resepsjon i barnehage, skole eller oppvekstsenter. Typisk innhold: timeplaner og vaktlister, beskjeder til elever og foresatte, bursdager, bilder fra aktiviteter, meny, kalender og nyheter.

Registrerte: barn og elever, foresatte, ansatte og besøkende. Kategorier: navn, bilde, klasse eller avdeling, fødselsdato ved bursdagsvisning, og fritekst som ansatte skriver.

Bruksområde B: helse- og omsorgsbygg

Skjermer i vestibyle, venterom, avdelingskorridor, pårørenderom og personalrom i sykehjem, omsorgsbolig, helsehus eller legesenter. Tillatt innhold er begrenset til generell drifts- og besøksinformasjon: åpningstider, veivisning, dagsplan og aktiviteter uten deltakerliste, generell måltidsmeny, praktiske beskjeder, kalender og nyheter.

Å vise navn, bilde eller romnummer på beboere og pasienter er ikke en akseptabel normalsituasjon i Vevet, og beskrives ikke som det her. At en navngitt person er beboer eller pasient på en helseinstitusjon, er i seg selv en helseopplysning etter GDPR art. 9. Tjenesten skal som standard ikke brukes til helseopplysninger, diagnoser, pasient- eller beboeridentifikasjon, biometriske data eller fødselsnummer, og hostingleverandørens standardvilkår åpner heller ikke for slike opplysninger uten uttrykkelig avtale.

Skal dette noen gang åpnes, kreves uttrykkelig kontraktsgrunnlag hos alle relevante leverandører, ny risikovurdering og DPIA, og skriftlig godkjenning før bruk. Vaktlister for ansatte og lignende personalinformasjon hører hjemme på skjermer i rom uten publikumstilgang.

Registrerte: ansatte, besøkende og pårørende. Kategorier: navn på ansatte i driftsinformasjon, og fritekst som ansatte skriver.

Behandlingens art: publisering av innhold på fysiske skjermer, med tidsstyring, tilgang per avdeling og en aktivitetslogg. Behandlingen innebærer ikke profilering, ikke automatiserte avgjørelser, ikke ansiktsgjenkjenning og ingen sammenstilling på tvers av kunder.

Del 2 — dataflyt

1. Innlogget bruker lager innhold i nettleseren, eventuelt med hjelp fra KI-hjelpen. Sender brukeren tekst til KI-hjelpen, går teksten fra vår server til Mistral sitt EU-endepunkt api.eu.mistral.ai (EU/EFTA-region) og tilbake. Bilder sendes aldri til KI.
2. Innholdet lagres i databasen og filer i fillageret, begge i EU. Alle rader er merket med organisasjon, og Row-Level Security i databasen hindrer at en annen organisasjon kan lese dem.
3. Innholdet publiseres til en kanal og tidsstyres (start, slutt, ukedager, klokkeslett).
4. Skjermen henter innholdspakken fra vår server med sitt eget skjerm-token, som ble utstedt ved paring med en kort, tidsbegrenset kode. Skjermen mellomlagrer siste innholdspakke lokalt, slik at den fortsetter å vise noe ved korte nettbrudd.
5. Innholdet vises i et fysisk rom. Dette er det viktigste punktet i hele vurderingen: skjermen er en offentlig synlig flate. Alle som er i rommet, kan lese innholdet, uavhengig av hvilke tilganger de har i systemet, og de kan fotografere det. Personvernet på en infoskjerm avgjøres derfor først og fremst av hva som publiseres og hvor skjermen står — ikke av tilgangsstyringen i verktøyet.
6. Sletting. Kunden sletter innhold selv. Aktivitetsloggen slettes automatisk etter 180 dager. Kamerabilder lagres aldri.

Del 3 — nødvendighet og forholdsmessighet

Formålet er å gi elever, beboere, pårørende, ansatte og besøkende praktisk informasjon på stedet. Behandlingen er egnet: en skjerm i fellesarealet når frem til dem som faktisk er der. Virksomheten bør sammenligne skjermvisning med aktuelle alternativer, som papir, e-post og SMS, og dokumentere hvorfor skjerm er nødvendig og forholdsmessig.

Dataminimering: behandlingen skal begrenses til det som må vises. Fornavn i stedet for fullt navn, ingen fødselsår, ikke diagnose eller andre helseopplysninger, ikke romnummer sammen med navn, og bilder bare der det er innhentet grunnlag.

Behandlingsgrunnlag settes av behandlingsansvarlig. Typisk art. 6 nr. 1 bokstav e (offentlig myndighet) for driftsinformasjon, og samtykke etter bokstav a for bilder og bursdager. Der grunnlaget er samtykke, må det være reelt frivillig og enkelt å trekke tilbake, og innholdet må fjernes fra skjermen når det trekkes.

Del 4 — risikovurdering

Sannsynlighet og konsekvens er satt ut fra et typisk oppsett. Kunden må justere dem etter egne rom og egen praksis.

Del 5 — rutiner hos behandlingsansvarlig

Hvem godkjenner innhold

[Fylles ut av behandlingsansvarlig] Anbefalt: avdelingen har en navngitt ansvarlig som godkjenner innhold som inneholder navn eller bilder av personer. Øvrig innhold kan publiseres direkte av redaktørene. Eksterne bidragsytere gis rollen som bare kan legge inn innhold, ikke administrere skjermer.

Hvor lenge innhold står

Anbefalt: alt innhold med personopplysninger får en sluttdato ved publisering, normalt maks 30 dager. Innhold uten sluttdato gjennomgås kvartalsvis.

Hva som aldri skal publiseres

• Helseopplysninger, diagnoser, medisinering eller behandlingsforløp.
• Fødselsnummer, adresse, telefonnummer eller romnummer knyttet til navngitt person.
• Opplysninger om barnevern, sosiale forhold, religion, etnisitet eller politisk syn.
• Personalsaker, sykefravær eller fraværsgrunner.
• Bilder av barn, elever, beboere eller pasienter uten dokumentert grunnlag.
• Navnelister som viser hvem som mottar en bestemt tjeneste.

Krav om sletting

Krav om sletting eller retting rettes til behandlingsansvarlig, som fjerner innholdet fra kanalen. Innholdet fjernes når skjermen henter neste oppdaterte innholdspakke. Filen slettes fra Mine filer dersom den ikke brukes andre steder. Behandlingsansvarlig bør notere hvem som ba om sletting og når. Trenger man bistand fra Vevet, gjelder databehandleravtalen punkt 9.

Del 6 — konklusjon og gjenstående tiltak

I eksempelsituasjonen kan tiltakene redusere risikoen. Behandlingsansvarlig må vurdere og dokumentere restrisikoen for egne lokaler, innholdstyper og registrerte. To forhold har fortsatt middels restrisiko og kan ikke løses teknisk av Vevet: feilpublisering av sensitiv fritekst, og at skjermen kan fotograferes. Begge må håndteres med rutine, opplæring og bevisst plassering av skjermene.

Gjenstående tiltak hos behandlingsansvarlig [Fylles ut av behandlingsansvarlig]: utpeke godkjenner per avdeling, vedta listen over hva som aldri publiseres, gjennomgå skjermplassering mot publikumsområder, avklare grunnlag for bilder og bursdager, og sette dato for neste gjennomgang av denne vurderingen.

Behandlingsansvarlig må vurdere behovet for forhåndsdrøfting etter art. 36. Dersom høy restrisiko består etter tiltak, skal Datatilsynet kontaktes før behandlingen starter. Vurderingen bør gjentas ved vesentlige endringer, for eksempel dersom skjermer med personopplysninger flyttes til publikumsarealer.

1. Standard vi følger

Vi arbeider mot WCAG 2.1 nivå AA, slik det er gjort bindende gjennom forskrift om universell utforming av IKT-løsninger. Kravene håndheves i Norge av Tilsynet for universell utforming av IKT (uu-tilsynet), under Digitaliseringsdirektoratet.

Plikten til å publisere en tilgjengelighetserklæring i uustatus.no gjelder offentlige virksomheter etter forskrift om universell utforming av IKT. Kravene til selve løsningen — WCAG 2.1 nivå AA — gjelder også private nettløsninger rettet mot allmennheten. DMZ DATA AS er et privat selskap, og publiserer derfor erklæringen direkte her på nettstedet. Lenken over er informasjon om ordningen, ikke en lenke til en erklæring fra oss.

Offentlige kunder kan bruke dokumentasjonen som teknisk underlag, men må selv kartlegge egen løsning, eget innhold og egen bruk i uustatus.no. Kontakt kontor@dmz.no for en oppdatert versjon.

2. Hva erklæringen omfatter

• Den innloggede appen — administrasjonen der brukere lager innhold, kanaler og skjermer.
• Visningsmodus — selve skjermvisningen som kjører på en fysisk skjerm.
• De offentlige sidene: forsiden, innlogging og de juridiske dokumentene.

Merk om visningsmodus: dette er en enveis informasjonsflate uten tastaturbetjening, laget for å leses på avstand. Enkelte WCAG-krav som forutsetter interaksjon (for eksempel tastaturnavigasjon og fokusrekkefølge) er ikke relevante der. Kravene til kontrast, tekststørrelse, tekstalternativ og bevegelse er relevante, og er behandlet under.

3. Status per krav i grove trekk

4. Kjente avvik

Innhold som bytter av seg selv i visningsmodus

Visningsmodus bytter innhold automatisk og mangler en mekanisme for pause eller styring av oppdateringsfrekvensen. Dette er registrert som avvik fra WCAG 2.2.2 og må vurderes og utbedres. Rulletekst (ticker) og sideskift i lister har samme begrensning. Kunden kan velge lengre visningstid per innhold for å gi mer lesetid.

Skjermleser er ikke testet systematisk

Administrasjonen er ikke systematisk testet med skjermleser. Omfang og tiltak må kartlegges.

Alt-tekst er valgfritt

Vi tvinger ikke frem alt-tekst på opplastede bilder. Det er kunden som avgjør, og et bilde uten beskrivelse vil mangle tekstalternativ.

PDF og innebygde nettsider

Innhold som viser en PDF eller en ekstern nettside, arver tilgjengeligheten til den filen eller siden. Tilgjengeligheten til PDF-er og innebygde nettsider avhenger også av kildematerialet. Kunden må kontrollere innholdet før publisering.

5. Bevegelse og prefers-reduced-motion

Vi har kontrollert dette i koden, og svaret er: delvis.

• Ber nettleseren om mindre bevegelse, slås effektene på innholdet av: rulletekst, sakte innzooming (Ken Burns), «mykt inn» og de dekorative animasjonene stopper helt.
• Overgangen «skyv sidelengs» mellom innhold byttes automatisk til en ren krysstoning uten forflytning.
• Krysstoningen selv, som bare endrer gjennomsiktighet over 800 millisekunder, beholdes. Den innebærer ingen forflytning eller skalering, men den er heller ikke slått helt av.
• Samme nedtrapping skjer automatisk på svak maskinvare og når bildefrekvensen måles under 30 bilder i sekundet.

6. Hva vi har gjort

• Bygget grensesnittet på standard HTML-elementer med tastaturstøtte.
• Synlig fokusmarkering på alt som kan få fokus.
• Automatisk kontrastberegning i temaene, med skjold bak tekst som ligger over foto.
• Dempet tekst utledes fra tekstfargen med en fastsatt minste synlighet, ikke fritt.
• Skriftstørrelse per skjerm (liten, medium, stor) med reell forstørrelse.
• Minstestørrelse på tekst i visningen — innhold kuttes heller enn å krympe.
• Status og varsler formidles med tekst i tillegg til farge.
• Respekt for prefers-reduced-motion som beskrevet i kapittel 5.
• Selvhostede skrifter, slik at teksten vises likt uten eksterne kall.

7. Meld fra om et tilgjengelighetsproblem

Finner du noe som ikke virker for deg, vil vi gjerne vite det — også små ting. Skriv til kontor@dmz.no. Beskriv gjerne hvilken side det gjelder, hvilket hjelpemiddel eller nettleser du bruker, og hva som skjedde.

Vi bekrefter mottak og gir informasjon om videre oppfølging.

Er du ikke fornøyd med svaret, kan du klage til Tilsynet for universell utforming av IKT via uustatus.no.