Tekniske og organisatoriske tiltak

Dette dokumentet publiseres på flere språk. Ved avvik mellom språkversjonene er den polske versjonen bindende.

Versjon 1.1 · Sist oppdatert: 22. oktober 2026

Tiltak etter personvernforordningen art. 32 som LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, bruker for å beskytte tjenesten formexposed. Denne siden er en del av Databehandleravtalen som vedlegg 2.

1. Virkeområde og prinsipp

Tiltakene gjelder alle opplysninger som tjenesten behandler: opplysningene vi behandler på vegne av Kundene våre (beskrevet i Databehandleravtalen), og opplysningene vi selv er behandlingsansvarlig for, som kundekontoer og logger. Det finnes ikke separate beskyttelsesnivåer for de to; det som beskytter kontoen, beskytter også databehandleropplysningene.

Struktur etter personvernforordningen art. 32(1). Pseudonymisering og kryptering (bokstav (a)) behandles i punkt 4; vedvarende konfidensialitet, integritet, tilgjengelighet og robusthet i systemene (bokstav (b)) i punkt 3, 5, 6 og 7; evnen til å gjenopprette tilgjengeligheten i rett tid etter en hendelse (bokstav (c)) i punkt 7.1; prosessen for regelmessig testing, vurdering og evaluering av effektiviteten (bokstav (d)) i punkt 9. Vi valgte tiltakene på grunnlag av risikoene beskrevet i Vurdering av personvernkonsekvenser vår, med hensyn til den tekniske utviklingen og gjennomføringskostnadene.

Prinsipp: målt fremfor planlagt. Bare det som faktisk er gjennomført i koden eller driften, oppgis her. Det som er planlagt, men ennå ikke gjennomført, er uttrykkelig oppført som «planlagt» i punkt 10. Et tiltak som mangler her, er ikke underforstått på plass.

Maskinnavn, interne adresser, porter, brukernavn og programvareversjoner oppgis bevisst ikke. De hjelper ingen med å vurdere tiltakene, men hjelper noen som ønsker å omgå dem. Den som trenger dem til en revisjon etter Databehandleravtalen, får dem under revisjonen under konfidensialitet, i den utstrekning de er nødvendige for revisjonen.

2. Tjenestens oppbygning

Tjenesten kjører på to av leverandørens egne servere i Polen, i det samme interne nettverket:

Nettserver med database. Den leverer applikasjonen, inneholder databasen, sender varslinger og sikkerhetskopierer opplysningene. Bare denne er satt opp til å ta imot forespørsler fra internett.
Skanneserver. Den utfører kontrollene av tredjepartsnettsteder og egne nettsteder i en nettleser og kjører språkmodellen som klassifiserer enkelte skjemaer, oppsummerer skannefunn som prioriterte tiltaksplaner for betalte kontoer og legger til kode i «Fix it for me». Den er ikke satt opp til å ta imot forespørsler fra internett, men henter selv jobbene sine fra nettserveren og returnerer resultatene dit.

Ingen hosting-, datasenter- eller skyleverandør er involvert i driften, og ingenting går til en ekstern KI-tjeneste. Hvilke tredjeparter som mottar opplysninger, er angitt på siden Underdatabehandlere.

3. Konfidensialitet

3.1 Kontroll av fysisk tilgang

Serverne befinner seg i leverandørens lokaler i Polen, som ikke er åpne for offentligheten. Bare eieren har tilgang (ifølge operatørens opplysninger). Den nøyaktige adressen til stedet oppgis bevisst ikke her.

3.2 Tilgangskontroll: innlogging i tjenesten

Passord lagres bare som en hash med PHPs standardmetode (bcrypt). Hvis standardmetoden endres, fornyes hashen ved neste innlogging. Ved et innloggingsforsøk med en ukjent adresse beregner serveren likevel en hash, slik at svartiden ikke avslører om en konto finnes. Tilsvarende avslører svaret på en forespørsel om tilbakestilling av passord verken gjennom ordlyden eller varigheten om kontoen finnes; tilbakestillings-e-poster sendes til samme adresse høyst tre ganger per time. Nye passord må være minst ti tegn lange og kan ikke overstige 72 byte (UTF-8), fordi bcrypt ikke tar hensyn til flere byte. Endring av passordet logger ut alle andre enheter; tilbakestilling via lenken logger ut alle enheter, og lenken er gyldig bare én gang.
Sperring etter mislykkede forsøk. Mislykkede innlogginger telles per IP-adresse; etter for mange på kort tid (for tiden åtte på 15 minutter) blokkeres innlogging fra denne adressen midlertidig. En vellykket innlogging nullstiller denne telleren. Forsøkene slettes etter sju dager. I tillegg telles før hver passordkontroll ett forsøk per konto (for en ukjent adresse per angitt adresse) og per IP-adresse, inkludert vellykkede forsøk: for tiden høyst åtte per konto fra samme IP-adresse og 80 per IP-adresse på 15 minutter; en betydelig høyere grense gjelder per konto på tvers av alle adresser samlet, mot distribuert gjetting. Mislykkede forsøk fra en annen adresse låser dermed ikke lenger eieren ute av en konto. Disse tellerne inneholder bare en HMAC-nøkkel, ingen e-post- eller IP-adresse i klartekst, og utløper med tidsvinduet. Hvis tellerlageret er utilgjengelig, avvises innloggingen i stedet for å slippes gjennom. Samme type grense gjelder bekreftelse av passordet før endring av passord eller adresse, aktivering eller deaktivering av andre faktor, overføring av et arbeidsområde, dataeksport og sletting av kontoen (fem forsøk per konto på 15 minutter), registreringer (ti per IP-adresse per time) og passord til kundeportaler (ti forsøk per portal og IP-adresse, 50 per portal på 15 minutter).
Andre faktor. Hver konto kan aktivere innlogging med en engangskode etter RFC 6238 (TOTP). Hemmeligheten til dette lagres kryptert i databasen; nøkkelen lagres ikke i databasen, så et databaseuttrekk alene er ikke tilstrekkelig. En godtatt kode er ikke gyldig en gang til. Ti gjenopprettingskoder lagres bare som en hash. Engangs- og gjenopprettingskoder er begrenset til ti forsøk per konto på 15 minutter, også under oppsett.
Administrasjonsområdet bare med andre faktor. Operatørens administrasjonsområde åpnes bare for kontoer med andre faktor aktivert. Sjekklisten for oppsett rapporterer hver administratorkonto uten andre faktor.
Økter. Øktkapselen kan ikke leses av skript (HttpOnly), sendes bare over HTTPS (Secure) og sendes ikke med forespørsler fra tredjepartsnettsteder som kan endre noe (SameSite=Lax). Ved innlogging opprettes en ny økt-ID, slik at en ID som er plassert på forhånd, ikke lenger er gyldig; serveren godtar ikke en økt-ID den ikke har utstedt selv. Hver konto ser sine innloggede enheter og kan logge dem ut enkeltvis.
«Hold meg innlogget» er valgfritt og er gyldig i 30 dager, men ikke for kontoer med administrasjonsrettigheter; de logger alltid inn med passord og andre faktor. Tokenen består av to deler; verifikasjonsdelen lagres i databasen bare som en hash. Hver bruk erstatter den med en ny, og selv ved samtidige forespørsler er hver token gyldig bare én gang, slik at en stjålet token oppdages senest ved neste reelle besøk.
Lenker i e-poster. Lenker for å bekrefte adressen og tilbakestille passordet lagres i databasen bare som en hash. Tilbakestillingslenken er gyldig i én time, lenken for å bekrefte en registrering i 72 timer, lenken for å bekrefte en endret adresse i 24 timer. Hvis e-postadressen endres, blir en åpen tilbakestillingslenke ugyldig.
Grensesnitt. API-nøkler, tilkoblingskoder for utvidelsene og utrullingskoder lagres bare som en hash. API-nøkler kan brukes bare et begrenset antall ganger per minutt; tilkoblingskoder for utvidelsene er gyldige i 15 minutter og bare én gang.
Botbeskyttelse på de offentlige skjemaene (registrering, innlogging, passord, kontroll, verktøy for HTTP-hoder, opt-out, kundestøtte og kontakt): Google reCAPTCHA, som bare lastes ved innsending. Bare et gyldig svar fra Google med tilstrekkelig poengsum for nøyaktig skjemaets handling godtas; hvis Google ikke svarer innen tre sekunder, avvises innsendingen. Detaljer finnes i Personvernerklæringen.

3.3 Tilgangskontroll: serveradministrasjon

Serveren som er tilgjengelig fra internett bruker et pakkefilter til å tillate bare tjenestene den tilbyr, og blokkerer automatisk adresser etter gjentatte mislykkede innlogginger til serveradministrasjonen.
Automatiserte prosesser mellom serverne bruker egne nøkler med snevert begrensede rettigheter. Nøkkelen som nettserveren bruker til å levere nye versjoner av skanneren, kan bare utføre en fast liste over kommandoer på skanneserveren og kan bare kopiere med ren skrivetilgang til skannerens katalog; interaktiv innlogging er ikke mulig med den, og hver avvist kommando logges. Tilsvarende kan skanneserveren bare skrive skjermbilder til en bestemt katalog på nettserveren.
Prosessen som leverer nettstedet, har verken skrivetilgang til produksjonsinstallasjonen eller en nøkkel til skanneserveren. En utrulling som utløses i administrasjonsområdet, oppretter bare en jobb, som en separat kjøring utfører.
Hemmeligheter som databaseopplysninger og nøkler oppbevares i konfigurasjonsfiler utenfor katalogen som leveres offentlig, og kopieres ikke med ved utrulling. Nettserverkonfigurasjonen distribueres ikke via nettgrensesnittet.

3.4 Rettighetskontroll: rettigheter i tjenesten

Roller. Hvert arbeidsområde har rollene eier, administrator og leser. Endring, sletting, invitasjon og lagring av innloggingsopplysninger er forbeholdt eiere og administratorer; bare eieren kan endre roller og fjerne medlemmer. En invitasjon er bare gyldig så lenge personen som sendte den, fortsatt er eier eller administrator. Lesere ser adressene til webhooks og chatkanaler bare forkortet til verten, fordi adressen alene gjør det mulig å poste til kanalen. Kontrollen skjer på serveren, ikke bare i grensesnittet.
Binding til arbeidsområdet. Domener og innstillinger er bare tilgjengelige for medlemmer av arbeidsområdet. For hver kontroll oppretter Tjenesten en rapport under en tilfeldig lenke som ikke kan gjettes; resultatene og skjermbildene fra en kontroll kan nås via denne lenken uten innlogging, skjermbilder bare sammen med lenken til rapporten. Lenken vises i kontoen og i varsler; den som videreformidler den, videreformidler rapporten.
Forespørsler som endrer tilstand krever en sikkerhetstoken per økt (CSRF-beskyttelse), som sammenlignes i konstant tid.
«Vis som kunde». For kundestøtte kan operatøren se applikasjonen slik en Kunde ser den. Visningen avsluttes etter én time, blokkerer endringer i passord, adresse, andre faktor, enheter, abonnement, eksport og sletting, stenger administrasjonsområdet i mellomtiden og logges. Avslutning logger operatøren helt ut; operatøren kan bare vende tilbake til administrasjonsområdet ved å logge inn på nytt med passord og andre faktor. Kunden kan se dette i dataeksporten sin.
Administrasjon. Bare noen få uttrykkelig autoriserte kontoer har administrasjonsrettigheter; hver tilbakestilling av en andre faktor fra administrasjonen logges.

3.5 Atskillelse

Kundenes opplysninger holdes logisk atskilt per arbeidsområde. Hver lese- og skrivevei i det innloggede området har denne bindingen med seg; rapporter er i tillegg tilgjengelige via lenken sin (punkt 3.4).
Utvikling og drift kjører i separate installasjoner med separate databaser og separate databasebrukere. Utviklingsbrukeren har ikke tilgang til produksjonsdatabasen. Reelle kundeopplysninger kopieres ikke til utvikling; der arbeider vi med genererte eksempeldata.
For hvert miljø har skanneren egne tilgangsopplysninger med rettigheter bare til opplysningene den trenger til jobbene sine. Den kan ikke lese kontoer, fakturering eller logger.
Andre tjenester fra samme leverandør kjører også på nettserveren. De har egne databaser og egne databasebrukere uten tilgang til denne tjenestens opplysninger.

4. Kryptering, pseudonymisering og dataminimering

4.1 Innloggingsopplysninger for skanning bak innlogging

For denne funksjonen lagrer Kunden brukernavnet og passordet til en testkonto. De er de mest følsomme opplysningene i tjenesten og beskyttes derfor annerledes enn alt annet:

Ved lagring krypterer nettserveren dem med skanneserverens offentlige nøkkel (ECIES: X25519 med en engangsnøkkel per oppføring, HKDF-SHA256, AES-256-GCM). Den private nøkkelen finnes bare på skanneserveren. Nettserver, database og sikkerhetskopier inneholder bare chiffertekst; heller ikke vi kan lese den der.
Hver oppføring er kryptografisk bundet til domenet sitt. Hvis den flyttes til et annet domene, mislykkes dekrypteringen.
For en skanning legges chifferteksten ved jobben. Skanneserveren dekrypterer den og sender innloggingsopplysningene til kontrollcontaineren bare via standard inndata, aldri som et kommandolinjeargument som ville vært synlig i prosesslister. Så snart skanneserveren har lest den, slettes chifferteksten fra jobben; en kjøring fjerner eventuelle rester senest etter én time.
Innloggingsopplysningene vises aldri, logges aldri, utleveres aldri via API-et og eksporteres ikke. Grensesnittet viser bare det første tegnet og lengden på brukernavnet. Fjerning overskriver chifferteksten.
Bak innloggingen leser skanneren bare: ingen innsending, ingen aktiv test, ingen skjermbilder, ingen sider for utlogging, sletting eller avbestilling.

4.2 Ytterligere kryptering og hasher

Passord, gjenopprettingskoder, kundeportalpassord, API-nøkler, tilkoblings- og utrullingskoder, «Hold meg innlogget»-tokener, økt-ID-er i enhetslisten og lenker for bekreftelse og tilbakestilling lagres bare som en hash.
Hemmeligheter for andre faktor lagres kryptert (punkt 3.2).
Vi hevder ikke at hele databasen er kryptert i hvile. De følsomme verdiene beskyttes enkeltvis som beskrevet ovenfor.

4.3 Innebygd dataminimering

Leveringskontroll: Bare hodene og høyst de første 8 KB av teksten leses. Bare tidspunktet, tilordningen, eventuelt ID-en til testinnsendingen og resultatet av autentisitetskontrollen (SPF, DKIM, DMARC) havner i databasen, aldri innholdet eller en fullstendig avsenderadresse. Autentisitetsresultatet for den siste e-posten beholdes med domenet og overskrives av den neste; det inneholder IP-adressen til den leverende e-postserveren og avsenderens e-postdomene. E-posten slettes fra postkassen etter vellykket behandling; hvis henting eller sletting mislykkes, skjer dette ved neste vellykkede kjøring.
Kontroller: Skjemastrukturen lagres med feltnavn, typer og etiketter, attributter for obligatoriske felt og synlighet, ingen verdier; skanneren leser begynnelsen av forhåndsutfylte skjulte felt (inntil 24 tegn) og dataattributter (inntil 60 tegn) bare under kontrollen og lagrer dem ikke. Skjermbildene fra den fullstendige kontrollen er ikke sladdet; bare nettleserkontrollene tildekker inndatafelt. Mottakeradresser i skjemaer lagres bare som et domene. Aktive testinnsendinger inneholder bare merkede testtekster uten personopplysninger.
Utvidelser for WordPress og TYPO3 overfører bare daglige tall og egenskaper som oversikten over tillegg, og for et tilkoblet WordPress-tillegg også domenene til lenker fra blokkerte meldinger for svermbeskyttelsen (slått på som standard); intet annet innhold, ingen navn, adresser eller IP-adresser til besøkende. Valgfrie skjematellinger og feltfeiltellinger er slått av som standard.
«Fix it for me»: Den innlimte koden behandles bare så lenge forespørselen varer, og lagres ikke.
Merke: Merkebildet på kunders nettsteder setter ingen informasjonskapsel og starter ingen økt.
Driftsvarslinger til operatørens telefon er faste tekster uten variabler, det vil si uten navn, adresser eller innhold. Feilvarslinger per e-post til operatøren inneholder råteksten til feilmeldingen, ikke renset, og avkortet til 400 tegn; i enkelttilfeller kan den inneholde adresser eller lenker.
Svermbeskyttelse: Mellom Kundenes utvidelser deles bare domener fra lenker i blokkert spam; utveksling av IP-nettverk er slått av.
Sted: Landet til en IP-adresse fastslås fra en lokal databasefil; ingen adresse går til en geolokaliseringstjeneste.

5. Beskyttelse mot misbruk av skanneren

Skanneren laster tredjepartssider med en reell nettleser. Uten beskyttelse ville den vært et verktøy som noen utenfra kunne bruke til å nå vårt interne nettverk eller andre ikke-offentlige mål (server-side request forgery). Derfor finnes to uavhengige lag og isolasjon av hver enkelt kjøring.

5.1 Isolert kjøring

Hver kontroll kjører i sin egen container, som fjernes etterpå. Den kjører uten administratorrettigheter, uten ytterligere operativsystemkapabiliteter og uten mulighet til å eskalere rettigheter. Filsystemet er skrivebeskyttet bortsett fra små, flyktige områder.
Minne, antall prosesser og kjøretid er begrenset; en kjøring som overskrider tiden, avsluttes.

5.2 Nettverk: to lag

Første lag, i skanneren: Før skanningen og deretter for hver enkelt forespørsel fra nettleseren, inkludert omdirigeringer og innebygd innhold, kontrolleres det hvilken adresse navnet slås opp til. Private, lokale, reserverte nettverk og dokumentasjonsnettverk (IPv4 og IPv6) avvises, og det samme gjelder andre porter enn de vanlige nettportene. Nettleseren tillater ikke service workers, og WebSocket-tilkoblinger lukkes, fordi begge kunne omgå denne kontrollen.
Andre lag, i nettverket: Containerne kjører i sitt eget nettverk. Brannmurregler tillater tilkoblinger derfra til internett bare på nettporter; tilkoblinger til private nettverk, inkludert vårt interne nettverk med nettserver og database, blokkeres. Unntak som selve kontrollkjøringen krever, er begrenset til det nødvendige og beskrevet i den interne dokumentasjonen vår. Dette laget virker også hvis et navn først slås opp annerledes etter den første kontrollen.

5.3 Forespørsler fra nettserveren

Der nettserveren selv forespør tredjepartsadresser – for dokumentasjon på kontroll over domenet, for verktøyet for HTTP-hoder, for søk etter tilgjengelige filer, for pulsforespørsler, for RDAP-forespørsler og kontroll av sertifikater, for webhooks og chatvarsler og for det valgfrie andre kontrollpunktet – gjelder de samme reglene: bare nettprotokoller på vanlige nettporter (webhooks og chatvarsler bare over HTTPS på standardporten), bare offentlige adresser, tilkobling bare til nøyaktig adressen som ble kontrollert på forhånd, slik at et navn ikke senere kan omdirigeres til et internt mål, omdirigeringer følges enten ikke i det hele tatt eller bare manuelt og med ny kontroll hver gang, korte tidsgrenser; for dokumentasjon på kontroll over domenet, pulsforespørsler og det andre kontrollpunktet i nettleserkontroller også en begrenset svarstørrelse.

5.4 Hva skanneren ikke gjør på tredjepartsnettsteder

Aktive testinnsendinger (høyst fem per kontroll) finnes for Kunder bare for domener der dokumentasjon på kontroll er gitt (DNS, metatagg, fil eller utvidelse); det eneste unntaket er interne kontroller av våre egne test- og demonstrasjonsdomener. Vertsnavnet til et domene med dokumentasjon på kontroll kan ikke endres, slik at dokumentasjonen ikke overføres til en annen vert. Alt annet er passivt: lesing av sider som en besøkende.
Nettleserkontroller går frem til punktet før innsending og utløser ingen bestilling, betaling eller innsending.
Domener på opt-out-listen kontrolleres ikke; løpende overvåking avsluttes ved neste planlagte kontroll.

6. Integritet: overføring og inndata

6.1 Transport

Applikasjonen er tilgjengelig fra internett bare via HTTPS; nettleseren instrueres om å bruke bare HTTPS i ett år (HSTS). Sertifikater fornyes automatisk.
Ytterligere hoder begrenser innbygging av applikasjonen i tredjepartssider, gjetting av filtyper og innsending av skjemaer til tredjepartsmål. En innholdssikkerhetspolicy lar bare skript som serveren godkjenner med det aktuelle svaret, kjøre i applikasjonen; moderne nettlesere utfører ikke injiserte skript eller hendelsesbehandlere i HTML-en.
Postkassen for leveringskontrollen hentes via en kryptert tilkobling med sertifikatkontroll.
Webhooks kan signeres med en hemmelighet fra Kunden (HMAC-SHA256 med tidsstempel), slik at mottakeren kan verifisere opprinnelse og integritet. Forespørsler til det valgfrie andre kontrollpunktet signeres, og for nettleserkontroller også svarene derfra.
Åpent oppgitt: Tilkoblinger i det interne nettverket vårt er ikke gjennomgående kryptert. Innloggingsopplysningene for skanning bak innlogging forblir kryptert gjennom hele prosessen (punkt 4.1).

6.2 Inndatakontroll og logger

Viktige handlinger i kontoer og arbeidsområder (som innlogging, endringer i domener, mottakersteder for varsler og rettigheter, slettinger, kundestøttetilgang) registreres i aktivitetsloggen med konto, tidspunkt, IP-adresse og land og slettes etter 365 dager.
Sideadgangsoppføringer som beholdes for sikkerhet og forebygging av misbruk, slettes etter 60 dager, feillogger etter 90 dager, innholdet i sendte e-poster etter 30 dager. Tilgangstokener i forespurte adresser og henvisningsadresser, som dem i rapport- eller portallenker, vises i sideadgangsoppføringene bare i maskert form.
Aksept av avtaledokumentene lagres med den viste versjonen, kontrollsummen, tidspunktet, IP-adressen og nettleseridentifikatoren.
Dokumentasjonslogger kan forsynes med et tidsstempel fra en ekstern tidsstemplingstjeneste; bare en kontrollsum av innholdet går til den, ikke selve innholdet.

7. Tilgjengelighet og robusthet

7.1 Sikkerhetskopiering

Databasen sikkerhetskopieres hver natt. En sikkerhetskopi får sitt endelige navn først etter at innholdet er kontrollert: vellykket fullføring av sikkerhetskopieringsprogrammet, minst én oppføring, like mange tabeller som databasen har, og avslutningslinjen fra en fullstendig kjøring. Eldre sikkerhetskopier fjernes bare etter at en ny er vellykket.
Hver sikkerhetskopi slettes etter 14 dager. Lagringsstedet er utenfor enhver katalog som leveres offentlig; et sted inne i prosjektet avvises.
Gjenopprettingstest: Én gang i uken lastes den nyeste sikkerhetskopien inn i en midlertidig database, sammenlignes tabell for tabell med produksjon og slettes igjen. Resultatet lagres.
Hvis en sikkerhetskopiering eller test mislykkes, sendes et varsel per e-post og til operatørens telefon.
Gjenoppretting etter en hendelse: Hvis databasen svikter eller opplysninger blir skadet, gjenoppretter vi den nyeste testede sikkerhetskopien. Endringer som er gjort siden denne sikkerhetskopien, som regel høyst endringene fra én dag, kan gå tapt i prosessen; hvis en sikkerhetskopiering har mislyktes, tilsvarende mer. Vi gjennomfører deretter kjente senere sletteanmodninger på nytt (punkt 8). Vi forplikter oss ikke til noen bestemt gjenopprettingstid.
Begrensning, åpent oppgitt: Sikkerhetskopiene lagres for tiden på samme sted som databasen og er ikke separat kryptert. De beskytter mot betjeningsfeil, feilaktige endringer og skadede data, ikke mot tap av selve serveren. En kryptert kopi på et annet sted er planlagt (punkt 10).
Innloggingsopplysningene for skanning bak innlogging finnes i sikkerhetskopiene bare som chiffertekst; hemmeligheten for andre faktor bare i kryptert form, med en nøkkel utenfor databasen.

7.2 Overvåking

En statuskjøring kontrollerer tjenestens komponenter hvert femte minutt, inkludert databasen, køen og skannerens livstegn, som skanneren skriver regelmessig også når den er inaktiv. Hvis en komponent svikter, sendes et varsel; hvis den kommer tilbake, et klarsignal.
Gjensidig overvåking: En statuskjøring kan ikke rapportere svikt i maskinen den kjører på. Skanneserveren kontrollerer derfor hvert minutt om applikasjonen svarer, og rapporterer etter flere påfølgende feil med en fast tekst til operatørens telefon. Omvendt overvåker nettserveren skannerens livstegn; sjekklisten for oppsett viser om den gjensidige overvåkingen kjører.
Feilvarsel: En feiltype som aldri har forekommet før, rapporteres én gang umiddelbart; en opphopning av feil utløser bare ett signal til operatørens telefon; én gang om dagen sendes en oversikt. Dermed får vi ikke først vite om en feil fra en Kunde.
Begrensning, åpent oppgitt: Begge serverne befinner seg på samme sted. Svikt på hele stedet, for eksempel i strøm eller internettilkobling, rapporteres ikke av noen varslingsmekanisme, men oppdages av et menneske.

7.3 Endringer og utrulling

Nye versjoner bygges og testes først i det separate utviklingsmiljøet. Utrullingen kontrollerer alle forutsetninger før den første filen skrives, utfører endringene i databaseskjemaet og lar pågående kontroller fullføres på en ordnet måte før skanneren starter på nytt.
For forløpet til en ny Kunde finnes en grunnleggende funksjonstest over reell HTTP som kjøres etter omlegginger. Vi hevder ikke at en automatisert testpakke kjøres før hver eneste utrulling.

8. Sletting og lagringstider

En slettekjøring hver natt håndhever periodene som er angitt i Personvernerklæringen og Databehandleravtalen. Den leser de samme innstillingene som tallene i tekstene hentes fra; for disse periodene avviker derfor ikke tekst og atferd fra hverandre.
Kontrollresultater inkludert skjermbilder slettes etter 13 måneder (det siste per domene beholdes), tall fra utvidelser etter 13 måneder, leveringslogger for varsler etter 90 dager, henvendelser til kundestøtte etter 24 måneder.
Fjerning av et domene sletter domenets opplysninger, inkludert kontroller, skjemaer, funn, skjermbilder, rapporter, jobber, mottakersteder for varsler og logger, hendelser, leveringsopplysninger, innloggingsopplysninger for skanning bak innlogging og dokumentasjon.
Sletting av en konto skjer umiddelbart; arbeidsområder uten flere medlemmer slettes med opplysningene sine, arbeidsområder med flere medlemmer overføres til et annet medlem, først til administratorer og blant dem til den som har vært medlem lengst. Frem til deres egne perioder utløper, beholdes følgende: loggene der oppføringene beholder det gamle kontonummeret, som ikke lenger viser til noen eksisterende konto, inkludert sletteoppføringen, samt sendte e-poster, dokumentasjonen på avtaleinngåelsen, henvendelser til kundestøtte, rapporter fra kontroller av potensielle kunder (inntil 90 dager) og faktureringsopplysninger hos Stripe; detaljer finnes i Personvernerklæringen.
Slettede opplysninger forblir i sikkerhetskopier frem til de utløper etter 14 dager. Målrettet sletting inne i en sikkerhetskopi skjer ikke; hvis en sikkerhetskopi gjenopprettes, gjennomføres kjente senere sletteanmodninger manuelt på nytt.

9. Organisering og gjennomgang

Personer: Tjenesten drives for tiden av eieren selv. Flere personer får tilgang først etter en konfidensialitetsforpliktelse og bare i nødvendig omfang, og de behandler opplysninger bare etter våre instrukser (personvernforordningen art. 29 og art. 32(4)).
Underdatabehandlere: Vi engasjerer dem først etter å ha vurdert garantiene deres og etter en avtale i henhold til personvernforordningen art. 28(4), og fører dem opp på siden Underdatabehandlere; detaljene reguleres av Databehandleravtalen.
Brudd på personopplysningssikkerheten: Hvis et slikt brudd berører databehandleropplysninger, varsler vi Kunden uten ugrunnet opphold, om mulig innen 48 timer; detaljene reguleres av Databehandleravtalen.
Rapportering av sårbarheter: Vi tar imot meldinger under Sikkerhet og via filen /.well-known/security.txt.
Sjekkliste for oppsett og lansering: I administrasjonsområdet måler en sjekkliste tilstanden til sikkerhetsrelevante innstillinger, som sikkerhetskopiering, administratorer uten andre faktor, e-postoppsett og livstegn, og viser avvik.
Gjennomgang av disse tiltakene (personvernforordningen art. 32(1)(d)): Ved hver vesentlige endring i tjenesten, etter hver sikkerhetshendelse og ellers minst én gang i året. Da vurderer vi om tiltakene er effektive og fortsatt svarer til risikoene, og dokumenterer resultatet i en ny versjon av denne siden eller, hvis ingenting endres, med datoen for gjennomgangen i punkt 11. Løpende måler sjekklisten for oppsett og lansering tilstanden til innstillingene den omfatter.
Eksterne revisjoner: Det bestilles for tiden ingen eksterne penetrasjonstester, og det finnes ingen sikkerhetssertifiseringer. Dette oppgis her slik at ingen antar at de finnes.

10. Planlagt, ennå ikke gjennomført

Disse punktene er ikke forpliktende tiltak før de er oppført her som gjennomført i en ny versjon:

Sikkerhetskopi på et annet sted: En kryptert kopi av den nattlige sikkerhetskopien utenfor serveren, slik at selv totalt tap av serveren ikke fører til tap av data.
Andre kontrollpunkt: Uavhengig bekreftelse av nettleserkontroller fra et annet sted er forberedt i tjenesten, men ikke satt opp. Uten den skjer ingen bekreftelse fra et annet sted.
Herding av serveradministrasjonen: Dette pågår. Av grunnene i punkt 1 publiserer vi ikke detaljer.

11. Status og versjon

Versjon 1.1 · Sist oppdatert: 22. oktober 2026 · ved avvik mellom språkversjonene har den polske versjonen forrang i stedet for den tyske; ingen annen endring.
Versjon 1.0 · Sist oppdatert: 11. oktober 2026 · første versjon som egen side; tidligere vedlegg 2 til Databehandleravtalen. Rettet sammenlignet med det tidligere vedlegget: Gjenopprettingstesten kjøres ukentlig, sikkerhetskopiene er på samme server, ingen automatisert testpakke kjøres før hver utrulling, tilkoblinger i det interne nettverket er ikke gjennomgående kryptert. Nytt beskrevet: kryptering av innloggingsopplysninger for skanning bak innlogging, isolering av skanneren, gjensidig overvåking og feilvarsler.
Endringer publiseres med nytt versjonsnummer her og i oversikten Endringer i avtaledokumentene; ved svekkelse av tiltak gjelder varslingsfristen i Databehandleravtalen.
Ved avvik mellom språkversjonene har den polske versjonen forrang.

Hvordan kan vi hjelpe?