DOKUMENT 1 — DATABEHANDLARAVTALE (DPA)

Versjon DPA v1.8 — 2026-10-03 (v1.7: 2026-10-03, v1.6: 2026-09-25, v1.5: 2026-09-25, v1.4: 2026-09-11, v1.3: 2026-09-08, v1.2: 2026-08-31, v1.1: 2026-07-29)

DATABEHANDLARAVTALE

Mellom

Behandlingsansvarleg (kunden):

[LAGETS/BEDRIFTA SITT NAMN]

Org.nr.: [ORG.NR]

Adresse: [ADRESSE]

Kontaktperson: [NAMN / E-POST]

heretter kalla «den behandlingsansvarlege»

og

Databehandlar (leverandøren):

Madsen Eventyr og Data

Org.nr.: 937 722 141

Tenestenamn: Hospo

Kontakt: post@hospo.no

heretter kalla «databehandlaren» eller «Hospo»

heretter samla kalla «partane».

Avtalen er inngått: [DATO]

1. Bakgrunn og føremål med avtalen

1.1 Den behandlingsansvarlege brukar tenesta Hospo, ei skybasert programvareteneste (SaaS) for små organisasjonar — frivillige lag/foreiningar og mindre bedrifter — mellom anna med ein styreportal for handsaming av styresaker, protokollar, vedtak, saksdokument, medlemsregister og signerte dokument.

1.2 For å levere tenesta handsamar Hospo personopplysningar på vegner av den behandlingsansvarlege. Denne avtalen regulerer rettane og pliktene til partane etter personvernforordninga (GDPR) artikkel 28, slik forordninga er gjennomført i norsk rett gjennom personopplysningslova.

1.3 Den behandlingsansvarlege avgjer føremålet med og midla for handsaminga. Hospo handlar berre etter dokumenterte instruksar frå den behandlingsansvarlege, jf. punkt 3.

1.4 Ved motstrid mellom denne avtalen og den generelle bruksavtalen/abonnementsavtalen for Hospo, går denne databehandlaravtalen føre når det gjeld handsaming av personopplysningar.

2. Omfanget av handsaminga (Art. 28 nr. 3, innleiing)

Følgjande beskriv kva handsaminga gjeld. Detaljane er fylte ut i Vedlegg A.

3. Databehandlaren handlar berre på dokumentert instruks (Art. 28 nr. 3 bokstav a)

3.1 Hospo skal berre handsame personopplysningar etter dokumenterte instruksar frå den behandlingsansvarlege, medrekna overføring til tredjeland, med mindre noko anna er kravd etter EØS-rett eller norsk rett som Hospo er underlagd. I så fall skal Hospo informere den behandlingsansvarlege om det rettslege kravet før handsaminga, med mindre lova forbyr slik informasjon.

3.2 Denne avtalen med vedlegg, saman med dei innstillingane og vala den behandlingsansvarlege gjer i tenesta, utgjer dei dokumenterte instruksane. Tilleggsinstruksar skal vere skriftlege.

3.3 Hospo skal straks varsle den behandlingsansvarlege dersom ein instruks etter Hospo si vurdering er i strid med personvernregelverket.

3.4 Hospo skal ikkje bruke personopplysningane til eigne føremål, og skal ikkje selje, leige ut eller på annan måte gjere opplysningane tilgjengelege for utanforståande utover det som følgjer av denne avtalen (sjå underdatabehandlarar, punkt 7).

3.5 Unntak for bruksstatistikk: Hospo kan handsame bruksstatistikk om korleis tenesta blir brukt (kva sider og funksjonar som blir opna, når, og av kva rolle) for å forbetre, feilsøkje og gje rettleiing i tenesta. Statistikken blir lagra på Hospo sin eigen tenar (Supabase, EU), utan informasjonskapslar og utan tredjepartsverktøy, og inneheld ikkje innhaldet i data den behandlingsansvarlege legg inn. Vanlege tilsette og medlemer blir ikkje identifiserte (berre organisasjon og rolle). For brukarar på eigar-, administrator- og leiarnivå kan brukar-ID lagrast, slik at Hospo kan ta kontakt om noko ser ut til å stoppe opp. Statistikken blir ikkje delt med utanforståande og blir sletta etter 13 månader.

3.6 Besøksteljing på gjestesidene: på gjestesidene den behandlingsansvarlege driv i Hospo (nettside, arrangement, booking, gåvekort, utleige) tel Hospo besøk på vegner av den behandlingsansvarlege: sidevisingar, side, referrer-domene, utm-kodar og fullførte handlingar (kjøp, påmelding, reservasjon). Teljinga brukar ikkje informasjonskapslar eller anna lagring på eininga til gjesten, og ingen tredjepart. Unike gjester per dag blir rekna som ein ikkje-reverserbar kode av IP-adresse og nettlesar med eit hemmeleg salt som skiftar dagleg; IP-adressa blir ikkje lagra. Gjester med Do Not Track eller Global Privacy Control blir ikkje talde. Tala er tilgjengelege for den behandlingsansvarlege i tenesta og blir sletta etter 13 månader.

3.7 Kortbetaling til den behandlingsansvarlege: Den behandlingsansvarlege kan ta imot kortbetaling i Hospo. Det gjeld billettar, gåvekort, utleige, medlemskort, depositum og kontingent. Då har den behandlingsansvarlege ein eigen konto hos Stripe og ein eigen avtale med Stripe om kontoen. Hospo set opp kontoen og opprettar betalingane på vegner av den behandlingsansvarlege. Hospo styrer òg når pengane blir betalte ut til bankkontoen, etter planen den behandlingsansvarlege vel. Til Stripe sender Hospo beløpet og e-postadressa til kjøparen, og for medlemskort òg namn og telefonnummer. Kjøparen skriv kortopplysningane rett inn hos Stripe, og Hospo lagrar dei ikkje. Stripe handsamar òg opplysningar til eigne føremål etter lov, som kundekontroll og tiltak mot kvitvasking og svindel. For desse føremåla er Stripe sjølvstendig behandlingsansvarleg etter eigne vilkår.

4. Teieplikt (Art. 28 nr. 3 bokstav b)

4.1 Hospo skal sikre at personar med tilgang til personopplysningane — medrekna operatøren personleg — har forplikta seg til teieplikt eller er underlagde ein passande lovfesta teieplikt.

4.2 Teieplikta gjeld også etter at avtaleforholdet er avslutta.

4.3 Tilgang til personopplysningane skal avgrensast til dei som treng tilgang for å oppfylle pliktene etter avtalen (prinsippet om minst mogleg tilgang). Hospo er ein éinpersonsoperatør; det inneber at operatøren teknisk har vid tilgang til underliggjande data (sjå punkt 6 og Vedlegg B for openheit om dette).

5. Tryggleik i handsaminga (Art. 28 nr. 3 bokstav c, jf. Art. 32)

5.1 Hospo skal setje i verk eigna tekniske og organisatoriske tiltak for å oppnå eit tryggleiksnivå som er tilpassa risikoen, jf. GDPR artikkel 32. Dei konkrete tiltaka er lista i Vedlegg B (Tekniske og organisatoriske tiltak — TOM).

5.2 Tiltaka omfattar mellom anna kryptering i transitt og i kvile, tilgangskontroll, isolasjon mellom kundar, sikkerheitskopiering og lagring innanfor EØS. Sjå Vedlegg B for det fulle biletet — medrekna kva tenesta i dag ikkje vernar mot.

5.3 Partane er samde om at tryggleiksnivået skal vurderast jamleg, og at tiltaka kan oppdaterast i takt med utvikling i teknologi, risiko og kva som er praktisk gjennomførbart for ein liten operatør. Vesentlege endringar som svekkjer vernet skal varslast den behandlingsansvarlege.

6. Særskilt om operatørtilgang og openheit (utfyller Art. 32)

Dette punktet handlar om kjernen i tillitsspørsmålet for styreportalen, og skildrar ærleg kva som er på plass i dag og kva som framleis er under arbeid.

6.1 Hospo driv tenesta på Supabase (database) og Vercel (hosting). Operatøren disponerer ein service-role-nøkkel og administrasjonstilgang til desse plattformene. Slik tilgang er teknisk naudsynt for drift, men inneber at operatøren i prinsippet kan lese innhald i databasen, medrekna protokollar, vedtak og medlemsregister.

6.2 Isolasjonen mellom kundar (Row-Level Security i Postgres) hindrar at ein kunde kan lese ein annan kunde sine data gjennom applikasjonen. Denne isolasjonen vernar ikkje mot operatøren, sidan service-role-nøkkelen og dashbord-tilgangen går utanom Row-Level Security.

6.3 Det realistiske og bransjenormale målet for ein éinpersonsoperatør er ikkje at operatøren teknisk skal vere ute av stand til å lese data, men at operatøren ikkje skal kunne lese data utan å etterlate eit spor som kunden kan sjå. Status i dag:

På plass:

• Kunde-synleg innsynsside («Kven har sett denne protokollen») med ein append-only, hash-kjeda innsynslogg som syner kven som har opna møte, protokollar og vedlegg gjennom tenesta, og når. Loggen er manipulasjons-sikker: kvar hending er kjeda til den førre, så endringar eller slettingar i ettertid kan oppdagast.

Under arbeid:

• Tilgangslogg på databasenivå (pgAudit) på privilegerte roller, med eksport i tilnærma sanntid til eit eksternt, ikkje-redigerbart lager (WORM/Object Lock) som operatøren ikkje administrerer. Dette vil fange opp lesing som skjer utanom applikasjonen (direkte databasetilgang).
• Redusert bruk av service-role i styreportal-rutene, slik at fleire operasjonar går gjennom kunden si eiga tilgang (RLS).

6.4 Hospo skal vere open og ærleg overfor den behandlingsansvarlege om kva tekniske kontrollar som faktisk er på plass til kvar tid, og skal ikkje framstille planlagde tiltak som ferdige. Den behandlingsansvarlege kan be om ein oppdatert status, jf. revisjonsretten i punkt 12.

7. Underdatabehandlarar (Art. 28 nr. 2 og nr. 4)

7.1 Den behandlingsansvarlege gjev generelt samtykke til at Hospo brukar underdatabehandlarar. Dei underdatabehandlarane som er i bruk på avtaletidspunktet, er lista i Vedlegg C.

7.2 Hospo skal påleggje kvar underdatabehandlar dei same databeskyttelsespliktene som følgjer av denne avtalen, gjennom ein eigen avtale (artikkel 28-vilkår).

7.3 Hospo skal varsle den behandlingsansvarlege om planlagde endringar som gjeld å leggje til eller skifte ut underdatabehandlarar, og gje den behandlingsansvarlege høve til å protestere mot endringa. Varsel skal givast i rimeleg tid, normalt minst [30] dagar før endringa trer i kraft. Dersom den behandlingsansvarlege protesterer og partane ikkje blir samde, kan den behandlingsansvarlege seie opp avtalen.

7.4 Hospo held fullt ansvar overfor den behandlingsansvarlege for at underdatabehandlarane oppfyller pliktene sine (jf. art. 28 nr. 4), og skal ved skriftleg avtale påleggje kvar underdatabehandlar dei same databeskyttelsespliktene som følgjer av denne avtalen — særleg tryggleik (art. 32) og sletteplikta ved opphøyr.

8. Overføring av personopplysningar til tredjeland (GDPR kapittel V)

8.1 Hovudregelen er at personopplysningar skal lagrast og handsamast innanfor EØS. Databaselagring (Supabase) og hosting (Vercel) er konfigurert til EU-region.

8.2 Særskilt om AI-funksjonane (USA): Hospo brukar Anthropic («Claude») til alle AI-funksjonar, mellom anna utkast til saksframlegg og vedtak, salsanalyse og bilagsklassifisering. Anthropic er ein amerikansk leverandør; tekst som blir send til AI-funksjonen kan dermed bli overført til USA. Dette er ei overføring til tredjeland som krev gyldig overføringsgrunnlag etter GDPR kapittel V:

• Anthropic stør seg på EUs standardpersonvernføresegner (SCC), modul 2, innbakt i Anthropic Commercial Terms, kombinert med ei overføringsvurdering (TIA). Anthropic opplyser kontraktsfesta at API-data ikkje trenar modellar, og at driftsloggar slettast etter 7 dagar.

8.3 For å redusere eksponeringa skal Hospo etterstreve å (a) avgrense kva data som blir send til AI, og (b) vurdere EU-basert AI-køyring der det finst ein EU-region for Anthropic, for å fjerne tredjelandsoverføringa. AI-funksjonane er valfrie og kan slåast av per organisasjon, jf. punkt 8.5.

8.4 So lenge AI-funksjonen sender data til USA, skal dette opplysast tydeleg overfor den behandlingsansvarlege, og påstandar om at «alle opplysningar blir lagra innanfor EØS» skal ikkje brukast utan atterhald.

8.5 Eigar eller Administrator i organisasjonen kan slå av alle AI-funksjonane under Innstillingar → Firma («AI i Hospo»). Då blir ingen tekst send til AI-leverandøren for organisasjonen. Den behandlingsansvarlege kan òg instruere Hospo om å slå dei av dersom tredjelandsoverføringa ikkje er ønskt.

9. Bistand til den behandlingsansvarlege ved rettane til dei registrerte (Art. 28 nr. 3 bokstav e)

9.1 Hospo skal, så langt det er mogleg, bistå den behandlingsansvarlege med eigna tekniske og organisatoriske tiltak slik at den behandlingsansvarlege kan oppfylle plikta si til å svare på førespurnader om utøving av rettane til dei registrerte, mellom anna:

• rett til innsyn,
• rett til retting,
• rett til sletting («retten til å bli gløymd»),
• rett til avgrensing av handsaminga,
• rett til dataportabilitet (utlevering i eit strukturert, vanleg og maskinlesbart format),
• rett til å protestere mot handsaminga.

9.2 Dersom ein registrert rettar ein førespurnad direkte til Hospo, skal Hospo utan ugrunna opphald vidareformidle førespurnaden til den behandlingsansvarlege, og ikkje sjølv svare på materielt innhald utan instruks.

10. Bistand ved tryggleik, avvik og vurderingar (Art. 28 nr. 3 bokstav f, jf. Art. 32–36)

10.1 Hospo skal bistå den behandlingsansvarlege med å oppfylle pliktene etter artikkel 32–36, medrekna tryggleik i handsaminga (art. 32), melding av brot til tilsynet og varsling til registrerte (art. 33/34), personvernkonsekvensvurderingar (DPIA, art. 35) og førehandsdrøfting med Datatilsynet (art. 36), når dette er relevant og praktisk mogleg, og under omsyn til arten av handsaminga og opplysningane Hospo har tilgang til.

Avvikshandtering og varsling (Art. 33/34)

10.2 Hospo skal utan ugrunna opphald etter at Hospo blir merksam på eit brot på personopplysningstryggleiken, varsle den behandlingsansvarlege. Varselet skal givast til [KONTAKTPUNKT HOS DEN BEHANDLINGSANSVARLEGE] og innehalde, så langt det er kjent:

• ei skildring av kva som har skjedd,
• kategoriane og talet på registrerte og opplysningar som er råka,
• truleg konsekvens,
• tiltak som er sette i verk eller er føreslegne.

10.3 Den behandlingsansvarlege er ansvarleg for å melde brotet til Datatilsynet innan 72 timar dersom brotet truleg medfører ein risiko for rettane og fridommane til fysiske personar, og for å varsle dei registrerte ved høg risiko (artikkel 34). Hospo kan berre melde til Datatilsynet på vegner av den behandlingsansvarlege dersom det er særskilt avtalt.

10.4 Hospo skal dokumentere alle brot og gjere dokumentasjonen tilgjengeleg for den behandlingsansvarlege.

11. Tilbakelevering og sletting ved opphøyr (Art. 28 nr. 3 bokstav g)

11.1 Når avtaleforholdet tek slutt, skal Hospo slette eller returnere alle personopplysningar, etter val frå den behandlingsansvarlege. Hospo skal òg slette eksisterande kopiar, med mindre EØS-rett eller norsk rett krev lagring.

11.2 Tilbakelevering: Den behandlingsansvarlege kan laste ned alle opplysningane sine når som helst fram til slettinga. Eigar og administrator kan laste ned. Når tenesta er sperra etter punkt 11.3, kan berre eigaren det. Nedlastinga er ei ZIP-fil med éi JSON-fil per tabell, som er eit strukturert og maskinlesbart format. Ho har òg filene som er lasta opp i tenesta, og ei oversikt over kva som er med. Store filmengder kjem i eigne ZIP-filer.

11.3 Frister ved oppseiing: Avtalen blir avslutta den siste dagen den behandlingsansvarlege har betalt for. I prøveperioden blir han avslutta same dag som oppseiinga. Frå dagen etter er tenesta sperra. Berre eigaren kan då logge inn, og berre for å laste ned opplysningane. Sidene gjester og medlemer brukar, er stengde. 30 dagar etter sperringa slettar Hospo alle opplysningane. Eigaren får e-post når sperringa startar, og 14 og 3 dagar før slettinga. Opplysningar som ikkje er lasta ned innan då, blir sletta.

11.4 Når Hospo set i gang slettinga: Er avtalen avslutta på annan måte, til dømes skriftleg, kan Hospo setje i gang slettinga. Tenesta blir då sperra med ein gong, og opplysningane blir sletta etter 7 dagar. Eigaren får e-post med ein gong og 3 dagar før. Hospo kan stoppe slettinga fram til då.

11.5 Kva som blir sletta: Hospo slettar alle rader i databasen som høyrer til den behandlingsansvarlege, og alle filer som er lasta opp. Innloggingane til brukarane blir òg sletta. Ei innlogging blir ståande berre når same brukar høyrer til ein annan kunde. Hospo-abonnementet i Stripe blir avslutta. Den behandlingsansvarlege sin eigen Stripe-konto blir ikkje sletta av Hospo, og opplysningane der er den behandlingsansvarlege sitt ansvar.

11.6 Ingen kopi: Etter slettinga har Hospo ingen kopi av opplysningane, utanom sikkerheitskopiane i punkt 11.8.

11.7 Slettelogg: Etter slettinga tek Hospo vare på ein slettelogg. Han har namnet, nettadressa og organisasjonsnummeret til den behandlingsansvarlege. Han har òg datoane for oppseiing og sletting, og kor mange rader og filer som vart sletta. Når Hospo har sett i gang slettinga, viser han kven hos Hospo som gjorde det. Sletteloggen har ingen opplysningar om dei registrerte og ikkje noko innhald. Han dokumenterer at slettinga er gjennomført. Hospo tek vare på sletteloggen i 5 år etter slettinga og slettar han deretter. Hospo skal på førespurnad stadfeste skriftleg at slettinga er gjennomført.

11.8 Sikkerheitskopiar: Sikkerheitskopiar av databasen, inkludert eventuell Point-in-Time Recovery, kan innehalde sletta opplysningar ei avgrensa tid. Dei forsvinn når kopien blir skifta ut. Hospo skal opplyse om backup-syklusen i Vedlegg B.

11.9 Lagringsplikt hos den behandlingsansvarlege: Hospo tek ikkje vare på opplysningar for den behandlingsansvarlege etter slettinga. Har den behandlingsansvarlege sjølv plikt til å lagre opplysningar, må han ta vare på dei gjennom nedlastinga før slettinga. Det gjeld til dømes bokføringspliktige opplysningar etter bokføringslova. Protokollar og vedtak er dokument organisasjonen òg bør ta vare på sjølv.

12. Revisjon og innsynsrett (Art. 28 nr. 3 bokstav h)

12.1 Hospo skal gjere tilgjengeleg for den behandlingsansvarlege all informasjon som er naudsynt for å vise at pliktene etter artikkel 28 blir oppfylte, og skal leggje til rette for og medverke til revisjonar, medrekna inspeksjonar, gjennomførte av den behandlingsansvarlege eller ein revisor utpeika av denne.

12.2 Revisjon skal varslast med rimeleg frist (normalt [30] dagar), gjennomførast i kontortid og ikkje uforholdsmessig forstyrre drifta. Den behandlingsansvarlege ber eigne kostnader ved revisjon, med mindre revisjonen avdekkjer vesentlege brot frå Hospo si side.

12.3 Hospo kan oppfylle dokumentasjonsplikta heilt eller delvis ved å leggje fram relevant dokumentasjon, t.d. tryggleiksdokumentasjon, sertifiseringar frå underdatabehandlarar (t.d. SOC 2) og tilgangsloggar.

13. Ansvar og mishald

13.1 Partane svarer etter gjeldande personvernregelverk. Den behandlingsansvarlege og Hospo kan kvar for seg bli pålagde administrative gebyr ved brot på regelverket.

13.2 Eventuelle avgrensingar av erstatningsansvar mellom partane følgjer av den underliggjande bruks-/abonnementsavtalen, men kan ikkje avgrense ansvar som etter ufråvikeleg rett ikkje kan avgrensast.

14. Varigheit, endringar og oppseiing

14.1 Avtalen gjeld så lenge Hospo handsamar personopplysningar på vegner av den behandlingsansvarlege.

14.2 Endringar i avtalen skal vere skriftlege. Hospo kan oppdatere vedlegga (særleg Vedlegg B og C) i takt med utviklinga i tenesta og underleverandørar; vesentlege endringar skal varslast, jf. punkt 7.3.

14.3 Avtalen kan seiast opp i samsvar med den underliggjande bruks-/abonnementsavtalen. Pliktene i punkt 4 (teieplikt) og punkt 11 (sletting/retur) gjeld også etter opphøyr.

15. Lovval og verneting

15.1 Avtalen er underlagd norsk rett.

15.2 Verneting er [STADEN DER DEN BEHANDLINGSANSVARLEGE HØYRER HEIME] tingrett, med mindre partane avtaler noko anna. For forbrukar-/foreiningskundar kan ufråvikelege vernetingsreglar gjelde.

Signaturar

Elektronisk signatur er tilstrekkeleg, jf. GDPR art. 28 nr. 9.

VEDLEGG A — Skildring av handsaminga

Behandlingsansvarleg: [LAGETS/BEDRIFTA SITT NAMN], org.nr. [ORG.NR]

A.1 Kategoriar av registrerte

• Medlemmer i laget/foreininga (medlemsregister)
• Styremedlemmer, varamedlemmer og tillitsvalde
• Tilsette (for bedriftskundar)
• Kundar/gjester (for bedriftskundar: booking, gåvekort, betaling)
• Billettkjøparar og deltakarar på arrangement (namn ved billettkontroll)
• Leigetakarar (utleige av lokale, utstyr, hamneplass o.l.)
• Kontaktpersonar og mottakarar av innkallingar/varsel

Merk: Medlemsregister i idrettslag og ungdomslag kan omfatte mindreårige. Den behandlingsansvarlege har ansvaret for at registreringa av mindreårige har gyldig grunnlag (normalt samtykke/avtale via føresette), og bør avgrense opplysningane til det naudsynte (t.d. fødselsår i staden for fullt fødselsnummer, slik tenesta legg opp til).

A.2 Typar personopplysningar

Merk: Habilitets-/inhabilitetsopplysningar (jf. asl. § 6-27) kan i visse tilfelle vere personleg sensitive. Den behandlingsansvarlege bør vurdere behandlingsgrunnlag særskilt for slike.

A.3 Behandlingsgrunnlag (den behandlingsansvarlege sitt ansvar)

• Medlemsregister: normalt medlemskapsavtale (art. 6 nr. 1 b) eller rettkomen interesse (art. 6 nr. 1 f); samtykke for ikkje-naudsynte føremål.
• Bokføringspliktige opplysningar: rettsleg plikt (art. 6 nr. 1 c).

Behandlingsgrunnlaget fastset den behandlingsansvarlege sjølv.

VEDLEGG B — Tekniske og organisatoriske tiltak (TOM), jf. Art. 32

Tiltak markert ✅ er på plass; tiltak markert 🔜 er under arbeid. Hospo gjentek ikkje planlagde tiltak som ferdige overfor kundar.

B.1 Tiltak som er på plass

• ✅ Kryptering i transitt (TLS) mot database, lagring og alle underleverandørar.
• ✅ Kryptering i kvile (AES-256) i databaseplattforma (Supabase).
• ✅ Isolasjon mellom kundar via Row-Level Security (RLS) i Postgres på styre-, medlems- og dokumenttabellar — hindrar at éin kunde les ein annan kunde sine data via applikasjonen.
• ✅ Tilgangskontroll på rollenivå internt i kvar kunde (leiarroller for sensitive funksjonar).
• ✅ Sikkerheitskopiering av databasen i same EU-region.
• ✅ Kryptert lagring av integrasjonsnøklar (Supabase Vault/pgcrypto) — gjeld API-nøklar, ikkje governance-innhald.
• ✅ Kunde-synleg, hash-kjeda (manipulasjons-sikker) innsynslogg for styreportalen, som syner kven som har opna møte, protokollar og vedlegg gjennom tenesta, og når.

B.2 Ærlege avgrensingar (det TOM-en i dag ikkje vernar mot)

• Operatørtilgang: Service-role-nøkkelen og dashbord-tilgangen går utanom RLS. Innhald (protokollar, vedtak, medlemsregister) er lagra i klartekst i databasen og kan i prinsippet lesast av operatøren. Innsynsloggen fangar opp tilgang som skjer gjennom applikasjonen, men ein logg på databasenivå (direkte tilgang utanom applikasjonen) er enno under arbeid, jf. B.3.
• Underleverandørar med innhaldstilgang: Anthropic (AI-utkast, USA) og Railway (PDF-konvertering) får faktisk governance-/protokollinnhald sendt til seg. Resend (e-post) og Sveve (SMS) får kontaktinfo og metadata. Sjå Vedlegg C.

B.3 Tiltak under arbeid

• 🔜 Tilgangslogg på databasenivå (pgAudit) på privilegerte roller, eksportert til eit eksternt, ikkje-redigerbart lager (WORM/Object Lock).
• 🔜 Redusert bruk av service-role i styreportal-rutene.
• 🔜 Applikasjonsnivå-kryptering av dei mest sensitive fritekstfelta, med nøkkel utanfor databasen (vernar mot dashbord-snoking og backup-lekkasje, men ikkje mot applikasjons-stien).

B.4 Organisatoriske tiltak

• ✅ Teieplikt for operatøren (punkt 4).
• ✅ Tofaktor-autentisering (MFA) på Supabase- og Vercel-kontoane.

VEDLEGG C — Liste over underdatabehandlarar

Lista nedanfor viser region, selskapsland, EU–US Data Privacy Framework-status og overføringsgrunnlag. Fleire underdatabehandlarar er vilkårsbundne — dei er berre i bruk dersom den behandlingsansvarlege tek i bruk den aktuelle funksjonen (markert «(valfri)»). DPF-status kan endre seg og bør kontrollerast på dataprivacyframework.gov ved behov.

Offentlege register som Brønnøysund (brreg.no) og Geonorge (adresseoppslag) er offentlege kjelder, ikkje databehandlarar. Sertifiseringar (t.d. SOC 2) kan dokumenterast på førespurnad.