Sikkerhet, personvern og datahåndtering

1.1 Hostingleverandør — ServeTheWorld (Oslo)

ServeTheWorld er en norskeid hostingleverandør med datasenter i Oslo. De er underlagt norsk selskapsrett og norsk personvernlovgivning. Dette betyr at data kun kan utleveres etter norsk rettskjennelse — ikke gjennom amerikanske lover som CLOUD Act eller FISA 702.

• •Geografisk plassering: Oslo, Norge — all infrastruktur i norsk jurisdiksjon
• •Sertifisering: ISO 27001 for informasjonssikkerhet
• •Strømforsyning: 90–95% vannkraft — blant verdens laveste CO₂-fotavtrykk
• •Sikkerhetskopiering: sikkerhetskopi hver time til egen backupserver i Oslo med ukentlig automatisk gjenopprettingstest, daglig kryptert kopi av hele maskinen, og ukentlig kryptert frakoblet kopi — alle kopier ligger i Norge
• •Latens: Under 5 ms for brukere i Norge

1.2 Serveroppsett

Buildex kjører på tre virtuelle servere hos ServeTheWorld i Oslo — til sammen 16 kjerner og rundt 40 GB RAM. Separasjonen mellom applikasjons- og databaselaget er en sikkerhetsarkitektur-beslutning: en sårbarhet i ett lag gir ikke automatisk tilgang til det andre.

1.3 Datatyper og lagring

All kundedata — både filer og strukturerte data — lagres utelukkende på norske servere i Oslo.

2.1 Under overføring

• •All kommunikasjon mellom bruker og Buildex skjer via HTTPS med TLS 1.2 eller nyere
• •Filoverføring til Nextcloud skjer via kryptert WebDAV — direkte mellom klient og server, ingen mellomledd
• •API-kall mellom interne tjenester er krypterte og autentiserte
• •HSTS (HTTP Strict Transport Security) er aktivert — nettlesere tvinges til sikker tilkobling
• •TLS-terminering skjer på Traefik (applikasjon) og Caddy (database-API), begge i samme datasenter som tjenesten — ingen edge-leverandør utenfor Norge

2.2 Lagrede data

• •Særlig sensitive felt — som fødselsnummer i eksponeringsregisteret og tilgangsnøkler til regnskapsintegrasjoner — krypteres i databasen før de lagres
• •Hemmeligheter som brukes av planlagte jobber lagres kryptert i Supabase Vault
• •Sikkerhetskopier: kopien av hele maskinen er kryptert, og den frakoblede kopien er kryptert med AES-256
• •Passord: Lagres aldri i klartekst — bcrypt med høy kostnadsfaktor

3.1 Rollebasert tilgangsstyring (RBAC)

3.2 Row Level Security (RLS)

All datatilgang håndheves på databasenivå via PostgreSQL Row Level Security. Dette betyr at selv en teknisk feil i applikasjonskoden aldri kan resultere i at en bruker ser data fra en annen bedrift. Tilgangsreglene er definert direkte i databasen og kan ikke omgås. RLS er aktivert på alle 426 tabeller, styrt av 1 146 tilgangsregler. Rollen avgjøres per prosjekt, ikke bare per bedrift — en bedrift kan være hovedbedrift på ett prosjekt og underentreprenør på et annet.

3.3 Isolasjon mellom bedrifter

Buildex er en multi-tenant plattform. Alle data er knyttet til en company_id og filteret håndheves på alle databasespørringer via RLS. Fillagringen i Nextcloud er organisert i separate mappestrukturer per bedrift, og ingen bruker kan aksessere en annen bedrifts område — verken via applikasjonen eller direkte mot lagringen.

4.1 Innloggingssikkerhet

• •JWT-tokens med kort levetid og automatisk fornyelse
• •Passord lagres med bcrypt-hashing — vi kan aldri lese ditt passord
• •Brute-force-beskyttelse: kontoer låses midlertidig etter gjentatte mislykkede innloggingsforsøk
• •Sesjoner invalideres umiddelbart ved utlogging
• •Separate miljøer for produksjon og staging — ingen testdata blandes med kundedata
• •Rate-limit-lag i applikasjonen blokkerer brute-force og automatiserte angrepsmønstre

4.2 To-faktor-autentisering (2FA)

Tofaktor (TOTP med autentikatorapp) kan slås på per konto. Kontoer med tofaktor må oppgi engangskode ved innlogging, og plattformens administratorkontoer må bruke tofaktor. Tofaktor settes opp under Innstillinger → Sikkerhet, med autentikatorapp som Google Authenticator, Microsoft Authenticator, 1Password, Bitwarden eller Authy. At bedriften selv kan kreve tofaktor for alle sine brukere, er under utvikling — kontakt oss dersom dette er et krav for din bedrift.

5.1 Behandlingsgrunnlag

• •Avtale (GDPR art. 6(1)(b)): Opplysninger som er nødvendige for å levere tjenesten til kunden
• •Berettiget interesse (art. 6(1)(f)): Logging av tilgangshendelser for sikkerhet og revisjon
• •Samtykke (art. 6(1)(a)): PSI-registrering og biometrisk data (HMS-kort med bilde)

5.2 Hvilke personopplysninger behandles

5.2.1 Innsjekkvarsel i mobilappen

Brukeren kan selv slå på varsel om innsjekk når de kommer til en byggeplass. Funksjonen er av som standard og kan slås av når som helst. Telefonens innebygde områdevarsling brukes til å avgjøre om brukeren er ved et prosjekt. Posisjonen vurderes kun på telefonen: den lagres ikke, sendes ikke til Buildex, og arbeidsgiveren har ikke tilgang til den. Buildex sender bare prosjektets adresse eller område til telefonen. Det sjekkes aldri inn automatisk — arbeidsgiveren ser kun innsjekkingen brukeren selv velger å gjøre.

5.3 Databehandleravtale (DPA)

Buildex inngår en standard databehandleravtale (DPA) i henhold til GDPR artikkel 28 med alle kunder. Avtalen regulerer:

• •Formål og omfang for databehandlingen
• •Tekniske og organisatoriske sikkerhetstiltak
• •Bruken av underdatabehandlere (se §9)
• •Prosedyrer ved sikkerhetsbrudd og varsling til Datatilsynet
• •Dataeksport og sletting ved avtaleopphør

5.4 Sletting og dataeksport

Ved avtaleopphør har kunden rett til å eksportere egne data inntil 30 dager etter opphør, jf. salgsvilkårene §18. Etter denne perioden slettes alle data permanent fra produksjonssystemene. Backup-kopier beholdes i inntil 90 dager av tekniske årsaker og slettes deretter.

• •Eksportformat: strukturert format etter forespørsel, filer i originalformat
• •Eksport i standard format er kostnadsfritt. Eksport utover standard format kan faktureres etter medgått tid, jf. salgsvilkårene §18
• •Skriftlig slettingsbekreftelse: Utstedes på forespørsel

6.1 Hvorfor Buildex er omfattet

CRA dekker «produkter med digitale elementer», inkludert programvare med nedlastbare komponenter. Buildex leverer både webapplikasjon og native mobilapper for iOS og Android. Mobilappene er nedlastbare komponenter som drar plattformen inn under CRA, og webapplikasjonen kvalifiserer som «remote data processing solution» — en sentral del av produktets funksjonalitet.

6.2 Buildex sine forpliktelser

Som «manufacturer» under CRA må Buildex:

• •Bygge sikkerhet inn i produktet fra designfasen og dokumentere dette
• •Vedlikeholde en Software Bill of Materials (SBOM) for alle leverte komponenter
• •Håndtere sårbarheter aktivt gjennom hele produktets livsløp
• •Rapportere aktivt utnyttede sårbarheter til ENISA innen 24 timer (varsel), 72 timer (detaljert rapport) og 14 dager (sluttrapport)
• •Levere sikkerhetsoppdateringer kostnadsfritt i hele den definerte støtteperioden
• •Gjennomføre conformity assessment og CE-merke produktet før 11. desember 2027

6.3 Hvordan Buildex sin arkitektur forenkler CRA-etterlevelse

Buildex sin selvhostede arkitektur på norsk infrastruktur reduserer CRA-kompleksitet sammenlignet med plattformer som er bygget på amerikanske skytjenester:

• •Færre underdatabehandlere å kartlegge og dokumentere i leverandørkjeden
• •Én sammenhengende stack som kan undersøkes uten å vente på tredjeparts disclosure-tidslinjer
• •Kontroll over patch-tempo uten avhengighet av Microsoft eller AWS sine release-planer
• •Direkte tilgang til logger og forensics-data ved hendelser, uten tredjeparts-leverandør i mellom

6.4 Sårbarhetsdisclosure

Sikkerhetsforskere, kunder og andre kan rapportere sårbarheter konfidensielt til support@buildex.no. Buildex svarer på alle henvendelser innen 48 timer og følger Coordinated Vulnerability Disclosure-prinsipper. Reglene for testing og varsling står på buildex.no/ansvarlig-varsling, og kontaktadressen i buildex.no/.well-known/security.txt.

6.5 Forholdet til andre regelverk

CRA komplementerer andre sikkerhets- og personvernregelverk Buildex etterlever:

• •GDPR — regulerer behandling av persondata (data-sentrert)
• •NIS2 — regulerer sikkerheten til organisasjoner som leverer kritiske tjenester (organisasjon-sentrert)
• •CRA — regulerer sikkerheten til selve produktet (produkt-sentrert)

Sammen utgjør disse en helhetlig regulatorisk ramme som Buildex sin fullt norske, selvhostede arkitektur er godt posisjonert til å møte.

7.1 Hva loggføres

• •Opplasting og nedlasting av filer (hvem, hva, når)
• •Opprettelse, endring og sletting av prosjekter og dokumenter
• •Tildeling og fjerning av brukerrettigheter
• •HMS-registreringer, avviksbehandling og sjekklistegjennomføringer
• •API-tilganger og feilhendelser
• •Bruk av den delte demokontoen (IP-adresse, nettleser/enhet og hvilke sider som åpnes) — for å forstå interessen for produktet. Kontoen er anonym; ingen navn lagres

7.2 Oppbevaring av logger

Tilgangs- og aktivitetslogger oppbevares i 24 måneder og slettes deretter automatisk. Hendelser fra demokontoen slettes etter 12 måneder, besøksoversikten etter 24 måneder. Loggene er skrivebeskyttede og kan ikke slettes av vanlige brukere. All loggdata lagres på norske servere i Oslo.

8.1 Varslingsrutiner

• •Kunder varsles uten unødig opphold og senest 72 timer etter at bruddet er oppdaget, jf. databehandleravtalen §11
• •Varselet inneholder: hendelsens art, berørte data, sannsynlige konsekvenser og iverksatte tiltak
• •Buildex bistår kunden med eventuelle meldeplikter til Datatilsynet
• •Alle sikkerhetsbrudd dokumenteres internt uavhengig av alvorlighetsgrad

8.2 Beredskapsplan

Vi har en dokumentert beredskaps- og gjenopprettingsplan (Disaster Recovery Plan) med følgende målsettinger:

• •RPO (Recovery Point Objective): Inntil 1 time — sikkerhetskopiene tas hver time, og gjenoppretting skjer til nærmeste hele time
• •RTO (Recovery Time Objective): Ikke tallfestet. Full gjenoppretting av en hel server fra VM-bilde er ennå ikke testet, og vi oppgir ikke et måltall vi ikke har målt
• •Backup-strategi: sikkerhetskopi hver time til egen backupserver i Oslo med ukentlig automatisk gjenopprettingstest, daglig kryptert kopi av hele maskinen, og ukentlig kryptert frakoblet kopi — alle kopier ligger i Norge
• •Gjenopprettingstest: Den nyeste databasekopien gjenopprettes automatisk hver uke i et isolert miljø, med kontroll av radtall

Følgende funksjoner sender innhold til Scaleway i Paris for AI-behandling: uttrekk fra sikkerhetsdatablad, kjemikaliesøk i stoffkartoteket, klassifisering av FDV-dokumenter, generering av fremdriftsplan, import av fremdriftsplan fra PDF og malimport. Ingen av dem sender data ut av EØS. Ved nettsøk etter sikkerhetsdatablad sendes bare produktnavn og leverandør til en europeisk søketjeneste. Innholdet i push-varsler krypteres med en nøkkel som bare den enkelte telefonen har; Expo, Apple og Google ser bare hva slags varsel det er (for eksempel «Ny RUH registrert»). Vi legger til nye underdatabehandlere kun etter varsling til berørte kunder og med mulighet for innsigelse.

9.1 Selvhostet — ikke underdatabehandlere

Følgende verktøy kjører på vår egen infrastruktur i Oslo og involverer ingen tredjeparter:

• •Monitorering: GlitchTip (feillogging), Umami (webstatistikk), Uptime Kuma (oppetid) — på egen driftsserver i Oslo
• •Plattform: Coolify — deployment og containerhåndtering
• •Backend: Selvhostet Supabase — autentisering, database, Storage API

10.1 Infrastrukturredundans

• •Hver time: database, filer og konfigurasjon kopieres over kryptert forbindelse til en egen backupserver i Oslo, og en kopi blir liggende på kildeserveren for rask gjenoppretting
• •Hver uke: den nyeste databasekopien gjenopprettes automatisk i et isolert miljø og kontrolleres mot radtall
• •Hver dag: kryptert kopi av hele maskinen for applikasjons- og databaseserveren (Acronis hos STW), med daglig, ukentlig og månedlig rullering
• •Hver uke: kryptert (AES-256) kopi til en frakoblet disk i Norge, verifisert med sjekksummer — den kopien som overlever at leverandøren selv er borte
• •Servere: tre virtuelle servere hos ServeTheWorld i Oslo — til sammen 16 kjerner og rundt 40 GB RAM, i ISO 27001-sertifisert datasenter
• •Planlagt vedlikehold: Varsles minimum 24 timer i forveien

10.2 Overvåkning

Systemet overvåkes kontinuerlig. Den eksterne tjenesten Better Stack driver den offentlige statussiden og overvåker at tjenesten svarer; den mottar kun oppetidssignaler og tekniske statuskoder, aldri kundedata. Varsler sendes til driftsteamet ved kritiske hendelser.

• •Offentlig statusside på status.buildex.no, overvåket fra utsiden av vårt eget datasenter — den varsler også når hele STW er nede
• •Helsesjekk som kontrollerer database og alle planlagte jobber, ikke bare at nettsiden svarer
• •Kontinuerlig feilovervåking med GlitchTip: alle feil som logges gås gjennom og rettes samme dag
• •Uptime Kuma for oppetid, på egen driftsserver i Oslo sammen med feilloggingen
• •Umami for webstatistikk — ingen cookies, ingen tredjepartssporing