Sikkerhed
De spørgsmål en bestyrelse stiller, før den vælger leverandør, besvaret ud fra, hvordan platformen faktisk er bygget.
Roller bestemmer, hvem der kan se hvad, og hvert kald til systemet kontrollerer en rettighed. Login-tokens ligger i cookies, som JavaScript ikke kan læse. Hver forenings data er adskilt og slås op ud fra det domæne, kaldet kommer ind på. Kortoplysninger indtastes hos betalingsudbyderen og rammer aldrig vores servere. AI-funktioner er slået fra, indtil foreningen slår dem til, og modellerne kører på vores egen infrastruktur. Foreningen er dataansvarlig, vi er databehandler.
Adgang styres af roller med enkeltrettigheder, ikke af et enkelt "administrator"-flag. Hvert kald til systemet kontrollerer den rettighed, det kræver, så en kasserer ikke kan åbne referater, og et almindeligt medlem ikke kan åbne administrationen. Moduler, foreningen ikke bruger, kan slås helt fra og forsvinder så fra menuen.
Adgangskoder gemmes aldrig i klartekst, men som saltede hashes. Login-tokens sendes som httpOnly-cookies, så JavaScript, og dermed et indsprøjtet script, ikke kan læse dem, og de er markeret secure og SameSite. Handlinger, der ændrer data, kræver desuden et CSRF-token, og den langlivede session udskiftes, hver gang den fornyes.
Hver række i databasen bærer den forening, den hører til, og alle opslag er begrænset til den. Hvilken forening et kald hører til, afgøres af det domæne, kaldet kommer ind på, ikke af noget klienten selv kan sende med. Oveni det skal brugeren have en rolle i netop den forening for at komme ind i administrationen.
Kortoplysninger indtastes på betalingsudbyderens egen side. Platformen får en ordrereference og en status tilbage og ser aldrig kortnummeret. Hver forening bruger sin egen nøgle til betalingsudbyderen; den kan indtastes, men aldrig læses tilbage, og vises kun maskeret.
Hændelser kan indberettes anonymt, og vælger indberetteren det, gemmes ingen identitet på sagen, heller ikke til senere brug. Hver sag har et fortrolighedsniveau, der afgør, hvem i foreningen der overhovedet kan åbne den, så en indberetning om en person ikke ligger frit tilgængeligt for hele bestyrelsen.
AI er slået fra, indtil foreningen slår det til, og bruges kun på den tekst, I selv giver den: omskrive et afsnit, opsummere et referat, svare ud fra jeres eget regelsæt. Modellerne kører på vores egen infrastruktur, ikke hos en ekstern modelleverandør, og hvert kald logges med sit forbrug, så det kan gøres op bagefter.
Siderne udsendes med en streng Content-Security-Policy, hvor hvert svar får sin egen nonce, så et script, vi ikke selv har lagt ind, ikke kan køre. HSTS binder trafikken til HTTPS. Skrifttyper og statistik hentes fra vores eget domæne, så ingen tredjepart følger jeres medlemmer rundt, og statistikken tælles først efter samtykke.
Foreningen er dataansvarlig og bestemmer, hvad der registreres, og hvem der får adgang. Vi er databehandler og behandler det kun for at drive tjenesten. I praksis er det vigtigste, I selv gør: hold listen over administratorer kort, og fjern adgangen, når en frivillig stopper.
Ja. Skriv til os, så sender vi den. Den underskrives sammen med jer, og teksten indgår i vilkårene, I kan læse på forhånd.
Vi sender den aktuelle liste på forespørgsel. Den hører til databehandleraftalen og ændres med forudgående varsel, så I kan gøre indsigelse, hvis vi skifter en leverandør.
Ja. Bogføringen kan hentes som SAF-T-fil direkte i systemet, og indsigts- og sletteanmodninger fra medlemmer håndteres i produktet. Skal I have alt med, fordi I stopper, leverer vi et samlet udtræk efter aftale.
Vi underretter jer uden unødig forsinkelse, når vi bliver opmærksomme på et brud, der berører jeres data, og giver de oplysninger, vi har, så I kan opfylde jeres egen underretningspligt. Det står i databehandleraftalen, ikke kun her.
Mere om data og vilkår: Sådan bruger vi data · Vilkår og databehandleraftale · Kontakt os