DOKUMENT 1 — DATABEHANDLARAVTALE (DPA)

Versjon DPA 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: patrick@mandelhuset.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).

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 AI-utkast av mellom anna saksframlegg og vedtak, og Google Gemini til AI-salsanalyse. Begge er amerikanske leverandørar; 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.
• Google LLC (Gemini) er sertifisert under EU–US Data Privacy Framework; overføring kan dermed byggje på DPF, subsidiært SCC. På betalt kvote brukast ikkje data til produktforbetring.

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 (t.d. Gemini via Vertex AI i EU-region, eller ein EU-region for Anthropic der det finst) 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 Den behandlingsansvarlege kan instruere Hospo om å slå av AI-funksjonen for sin organisasjon 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. Sletting og retur ved opphøyr (Art. 28 nr. 3 bokstav g)

11.1 Ved opphøyr av avtaleforholdet skal Hospo, etter den behandlingsansvarlege sitt val, slette eller returnere alle personopplysningar, og slette eksisterande kopiar, med mindre EØS-rett eller norsk rett krev lagring.

11.2 Den behandlingsansvarlege vel om opplysningane skal returnerast (eksport i strukturert format) eller slettast. Dersom val ikkje er gjort innan [30] dagar etter opphøyr, skal opplysningane slettast.

11.3 Hospo skal på førespurnad stadfeste skriftleg at sletting er gjennomført.

11.4 Unntak for lovpålagd lagring: Visse opplysningar kan vere underlagde lovpålagd lagringsplikt som går føre sletting, særleg bokføringspliktige opplysningar etter bokføringslova. Protokollar og vedtak kan dessutan vere governance-dokument som organisasjonen sjølv ønskjer å ta vare på; lagringstid for slike styrer den behandlingsansvarlege sjølv.

11.5 Backup-kopiar (inkludert eventuell Point-in-Time Recovery) kan innehalde sletta data i ein avgrensa periode til backupen blir rotert ut. Hospo skal opplyse om backup-syklusen i Vedlegg B.

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.