Sikkerhet og etterlevelse

Hvordan vi beskytter dataene vi får tilgang til når vi ser etter svakheter i deres

Vi ber om innsyn i sårbarhetene deres. Da skylder vi dere en konkret redegjørelse for hvordan den innsikten oppbevares, hvor lenge, og hvem som kan se den.
Kortversjon

Data om deres svakheter er de dataene vi passer aller best på.

Funn fra en skanning er et kart over hvor dere er sårbare. Derfor lagres de kryptert, i EU, med automatisk sletting og med tilgang begrenset til de som må ha det.

Vi lover ikke sertifiseringer vi ikke har. Under står både tiltakene og hullene.

Kundedata lagres i EU

Portal, database og skanninfrastruktur kjører hos leverandører i EU, med skanning i AWS eu-north-1 (Stockholm).

Skanning kjører adskilt

Skanningen kjøres i egne containere, isolert fra kundeportalen og fra hverandres kunder.

Data slettes automatisk

Rådata fra skanning slettes etter 7 dager, ferdige rapporter etter 90 dager. Ingen manuell opprydding kreves.

1

Isolasjon av skanning

Skanningen kjører på egen infrastruktur i AWS-regionen eu-north-1 (Stockholm), adskilt fra kundeportalen og portalens database. En feil eller overbelastning i skanningen skal ikke kunne velte portalen, og omvendt.

Skanneoppdrag kjøres i containere som bygges fra versjonerte, kjente images og erstattes i sin helhet ved hver utrulling. Resultater knyttes til den enkelte kunden og skrives til atskilte lagringsområder, slik at én kundes skann aldri leser fra en annen kundes data.

Kommunikasjonen mellom portalen og skanninfrastrukturen er signert med HMAC. En forespørsel uten gyldig signatur avvises, selv om den kommer fra riktig nettverk.

2

Hvor data behandles

Kundedata lagres i EU. Portalen driftes hos Vercel med databasen i EU, autentisering og lagring hos Supabase i EU, og skanninfrastrukturen i AWS eu-north-1.

Enkelte underdatabehandlere behandler data utenfor EU. Det gjelder blant annet OpenAI, Stripe, Resend og Have I Been Pwned. Overføringen skjer på EU-kommisjonens standard personvernbestemmelser (SCC) eller tilsvarende gyldig grunnlag.

Vi sier derfor at data lagres i EU, ikke at alt utelukkende behandles i EU. Den fulle listen over underdatabehandlere ligger i databehandleravtalen.

3

Sletting og lagringstid

Data vi ikke trenger, er data som kan lekke. Slettingen er derfor automatisk og bygget inn i lagringen, ikke avhengig av at noen husker å rydde.

DatatypeHva det erLagringstidMerknad
Rådata fra skanningUbehandlet utdata fra skanneverktøyene7 dagerSlettes automatisk av livssyklusregler i lagringen.
RapporterGenererte PDF-rapporter og funn90 dagerSlettes automatisk. Last ned rapporter du vil beholde lenger.
KontodataBruker, virksomhet, overvåkede domener og e-posterSå lenge kundeforholdet varerSlettes eller returneres ved opphør, i tråd med databehandleravtalen.
Gratis sikkerhetssjekkDomene eller e-post sendt inn uten innloggingIkke lagret permanentBrukes til å kjøre kontrollen og vise resultatet i nettleseren.
RevisjonsloggHvem gjorde hva i portalenSå lenge kundeforholdet varerNødvendig for sporbarhet og for kundens egen dokumentasjon.

Vil dere ha kontoen og tilhørende data slettet før tiden, holder det å be om det på personvern@vernix.no. Sletting utføres uten unødig opphold, og vi bekrefter når det er gjort.

4

Tekniske og organisatoriske tiltak

Kryptering

All trafikk går over TLS med HSTS påslått, og data ligger kryptert i lagringen hos databaseleverandøren. Nøkkelen som signerer skanneoppdrag forlater aldri AWS KMS, så tilgang til portalen gir ikke i seg selv retten til å starte en skanning.

Ingen passordlagring

Vi behandler ikke kundens passord. Innlogging skjer med engangslenke på e-post, så det finnes ingen passorddatabase å stjele.

Tilgangsstyring

Tilgang til produksjonsdata er begrenset til de som trenger det for drift, og handlinger i portalen logges i en revisjonslogg.

Beskyttelse mot misbruk

Rate limiting på API-endepunkter, botbeskyttelse på skjemaer, og validering av opphav på alle forespørsler som endrer data.

Herdet nettleserkontekst

Streng Content-Security-Policy, X-Frame-Options DENY og restriktiv Permissions-Policy begrenser skadeomfanget hvis noe skulle bli injisert.

Sikker utvikling

Statisk kodeanalyse (CodeQL) og automatisk varsling om sårbare avhengigheter (Dependabot) kjører på kodebasen, og endringer går gjennom kodegjennomgang.

5

Håndtering av hendelser

Ved brudd på personopplysningssikkerheten varsler vi berørte kunder uten ugrunnet opphold, og gir informasjonen kunden trenger for sin egen varslingsplikt til Datatilsynet.

Sårbarheter som meldes inn utenfra håndteres etter retningslinjene for ansvarlig varsling.

6

Det vi ikke påstår

Vi er ikke ISO 27001-sertifisert eller SOC 2-revidert i dag. Tiltakene på denne siden er reelle, men de er ikke verifisert av en ekstern revisor, og vi presenterer dem ikke som om de var det.

Vi kan heller ikke garantere at all risiko oppdages. Tjenesten bygger på tilgjengelige kilder og signaler, og ingen leverandør ser alt.

Ber dere om sikkerhetsdokumentasjon i en anskaffelse, svarer vi på spørreskjemaer med det som faktisk gjelder, ikke med ambisjoner.

7

Kundens eget ansvar

Aktiv skanning kjøres kun mot domener kunden selv har bekreftet eierskap til. Dere er ansvarlige for at dere har rett til å teste det dere legger inn.

Dere er også ansvarlige for egne tilganger i portalen, og for hvilke sikkerhetsbeslutninger som tas basert på anbefalingene våre.

Sist oppdatert: 10. august 2026
Funnet en svakhet hos oss?

Vi vil heller høre det fra deg enn fra noen andre

Meld sårbarheter i våre egne systemer etter retningslinjene for ansvarlig varsling. Du får svar, og du blir ikke møtt med jurister.