Tekniske og organisatoriske foranstaltninger

Dette dokument er offentliggjort på flere sprog. I tilfælde af uoverensstemmelser mellem sprogversionerne er den polske version bindende.

Version 1.1 · Senest opdateret: 22. oktober 2026

Foranstaltninger efter art. 32 GDPR, hvormed LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, beskytter tjenesten formexposed. Denne side udgør en del af databehandleraftalen som bilag 2.

1. Anvendelsesområde og princip

Foranstaltningerne gælder for alle data, som tjenesten behandler: for de data, vi behandler på vegne af vores Kunder (beskrevet i databehandleraftalen), og for de data, som vi selv er dataansvarlige for, såsom kundekonti og logfiler. Der er ikke separate beskyttelsesniveauer for de to; det, der beskytter kontoen, beskytter også databehandlerdataene.

Opbygning efter art. 32(1) GDPR. Pseudonymisering og kryptering (litra a) behandles i afsnit 4; systemernes vedvarende fortrolighed, integritet, tilgængelighed og robusthed (litra b) i afsnit 3, 5, 6 og 7; evnen til rettidigt at genoprette tilgængeligheden efter en hændelse (litra c) i afsnit 7.1; proceduren for regelmæssig afprøvning, vurdering og evaluering af effektiviteten (litra d) i afsnit 9. Vi har udvalgt foranstaltningerne på grundlag af de risici, der er beskrevet i vores konsekvensanalyse vedrørende databeskyttelse, under hensyntagen til det aktuelle tekniske niveau og implementeringsomkostningerne.

Princip: målt frem for tilsigtet. Kun det, der faktisk er gennemført i koden eller i driften, er angivet her. Det, der er planlagt, men endnu ikke gennemført, er udtrykkeligt opført som »planlagt« i afsnit 10. En foranstaltning, der mangler her, er ikke stiltiende på plads.

Navne på maskiner, interne adresser, porte, brugernavne og softwareversioner er bevidst ikke angivet. De hjælper ingen med at vurdere foranstaltningerne, men de hjælper den, der vil omgå dem. Den, der har brug for dem til en audit efter databehandleraftalen, får dem i forbindelse med denne audit under fortrolighed, i det omfang de er nødvendige for auditten.

2. Tjenestens opbygning

Tjenesten kører på to af udbyderens egne servere i Polen, der står i samme interne netværk:

Webserver med database. Den leverer applikationen, rummer databasen, sender notifikationer og sikkerhedskopierer dataene. Kun den er sat op til at modtage forespørgsler fra internettet.
Scanningsserver. Den udfører kontrollerne af tredjeparters og egne websites i en browser og kører den sprogmodel, der klassificerer enkelte formularer og tilføjer kode i »Fix it for me«. Den er ikke sat op til at modtage forespørgsler fra internettet, men henter selv sine jobs fra webserveren og returnerer resultaterne dertil.

Ingen hosting-, datacenter- eller cloududbyder er involveret i driften, og intet går til en ekstern AI-tjeneste. Hvilke tredjeparter der modtager data, fremgår af siden Underdatabehandlere.

3. Fortrolighed

3.1 Fysisk adgangskontrol

Serverne står i lokaler tilhørende udbyderen i Polen, som ikke er offentligt tilgængelige. Kun ejeren har adgang (ifølge operatørens oplysninger). Placeringens nøjagtige adresse er bevidst ikke angivet her.

3.2 Adgangskontrol: login i tjenesten

Adgangskoder gemmes kun som hash med PHP's standardmetode (bcrypt). Hvis standardmetoden ændres, fornyes hashen ved næste login. Ved et loginforsøg med en ukendt adresse beregner serveren alligevel en hash, så svartiden ikke afslører, om en konto findes. Ligeledes afslører svaret på en anmodning om nulstilling af adgangskode hverken ved sin ordlyd eller sin varighed, om kontoen findes; nulstillings-e-mails sendes højst tre gange i timen til samme adresse. Nye adgangskoder skal være mindst ti tegn lange og må ikke overstige 72 byte (UTF-8), fordi bcrypt ikke tager flere byte i betragtning. En ændring af adgangskoden logger alle andre enheder ud; nulstilling via linket logger alle enheder ud, og linket er kun gyldigt én gang.
Spærring efter mislykkede forsøg. Mislykkede logins tælles pr. IP-adresse; efter for mange inden for kort tid (i øjeblikket otte på 15 minutter) spærres login fra denne adresse midlertidigt. Et vellykket login nulstiller denne tæller. Forsøgene slettes efter syv dage. Derudover tælles før hver kontrol af adgangskoden ét forsøg pr. konto (for en ukendt adresse pr. indtastet adresse) og pr. IP-adresse, vellykkede forsøg medregnet: i øjeblikket højst otte pr. konto fra samme IP-adresse og 80 pr. IP-adresse på 15 minutter; pr. konto på tværs af alle adresser tilsammen gælder en betydeligt højere grænse mod distribueret gætning. Mislykkede forsøg fra en anden adresse spærrer derfor ikke længere ejeren ude af en konto. Disse tællere indeholder kun en HMAC-nøgle, ingen e-mail- eller IP-adresse i klartekst, og udløber med deres tidsvindue. Hvis tællerlageret ikke er tilgængeligt, afvises login i stedet for at blive lukket igennem. Samme type grænse gælder for bekræftelse af adgangskoden før en ændring af adgangskode eller adresse, aktivering eller deaktivering af anden faktor, overdragelse af et workspace, dataeksporten og sletning af kontoen (fem forsøg pr. konto på 15 minutter), for registreringer (ti pr. IP-adresse i timen) og for adgangskoder til kundeportaler (ti forsøg pr. portal og IP-adresse, 50 pr. portal på 15 minutter).
Anden faktor. Alle konti kan aktivere login med en engangskode efter RFC 6238 (TOTP). Hemmeligheden hertil gemmes krypteret i databasen; nøglen gemmes ikke i databasen, så et udtræk af databasen alene ikke er nok. En accepteret kode er ikke gyldig en gang til. Ti gendannelseskoder gemmes kun som hash. Engangs- og gendannelseskoder er begrænset til ti forsøg pr. konto på 15 minutter, også under opsætningen.
Administrationsområde kun med anden faktor. Operatørens administrationsområde åbner kun for konti med aktiveret anden faktor. Opsætningstjeklisten rapporterer enhver administratorkonto uden anden faktor.
Sessioner. Sessionscookien kan ikke læses af scripts (HttpOnly), sendes kun via HTTPS (Secure) og sendes ikke med forespørgsler fra tredjepartssider, der kunne ændre noget (SameSite=Lax). Ved login oprettes et nyt sessions-ID, så et ID, der er plantet forinden, ikke længere er gyldigt; serveren accepterer ikke et sessions-ID, som den ikke selv har udstedt. Alle konti kan se deres indloggede enheder og logge dem ud enkeltvis.
»Forbliv logget ind« er valgfrit og gælder i 30 dage, dog ikke for konti med administrationsrettigheder; de logger altid ind med adgangskode og anden faktor. Tokenet består af to dele; den verificerende del gemmes kun som hash i databasen. Hver brug erstatter den med en ny, og selv ved samtidige forespørgsler er hvert token kun gyldigt én gang, så et stjålet token opdages senest ved næste ægte besøg.
Links i e-mails. Links til bekræftelse af adressen og nulstilling af adgangskoden gemmes kun som hash i databasen. Nulstillingslinket er gyldigt i en time, linket til bekræftelse af en registrering i 72 timer, linket til bekræftelse af en ændret adresse i 24 timer. Hvis e-mailadressen ændres, bliver et åbent nulstillingslink ugyldigt.
Grænseflader. API-nøgler, forbindelseskoder til udvidelserne og udrulningskoder gemmes kun som hash. API-nøgler kan kun bruges et begrænset antal gange pr. minut; forbindelseskoder til udvidelserne er gyldige i 15 minutter og kun én gang.
Botbeskyttelse på de offentlige formularer (registrering, login, adgangskode, kontrol, header-værktøj, opt-out, support og kontakt): Google reCAPTCHA, som først indlæses ved indsendelse. Kun et gyldigt svar fra Google med tilstrækkelig score for netop formularens handling accepteres; hvis Google ikke svarer inden for tre sekunder, afvises indsendelsen. Detaljer findes i privatlivspolitikken.

3.3 Adgangskontrol: serveradministration

Den server, der kan nås fra internettet, tillader via et pakkefilter kun de tjenester, den tilbyder, og spærrer automatisk adresser efter gentagne mislykkede logins til serveradministrationen.
Automatiserede processer mellem serverne bruger deres egne nøgler med snævert begrænsede rettigheder. Den nøgle, hvormed webserveren leverer nye versioner af scanneren, må kun udføre en fast liste af kommandoer på scanningsserveren og må kun kopiere, skrivebeskyttet i én retning, ind i scannerens mappe; et interaktivt login er ikke muligt med den, og enhver afvist kommando logges. Ligeledes må scanningsserveren kun skrive skærmbilleder til en bestemt mappe på webserveren.
Den proces, der leverer websitet, har hverken skriveadgang til produktionsinstallationen eller en nøgle til scanningsserveren. En udrulning, der udløses i administrationsområdet, opretter kun et job, som en separat kørsel udfører.
Hemmeligheder som databaseloginoplysninger og nøgler opbevares i konfigurationsfiler uden for den leverede mappe og kopieres ikke med ved udrulning. Webserverens konfiguration distribueres ikke via webgrænsefladen.

3.4 Autorisationskontrol: rettigheder i tjenesten

Roller. Hvert workspace har rollerne ejer, administrator og læser. Ændring, sletning, invitation og lagring af loginoplysninger er forbeholdt ejere og administratorer; kun ejeren må ændre roller og fjerne medlemmer. En invitation er kun gyldig, så længe den person, der har sendt den, stadig er ejer eller administrator. Læsere ser kun adresserne på webhooks og chatkanaler forkortet til hosten, fordi adressen alene gør det muligt at skrive i kanalen. Kontrollen sker på serveren, ikke kun i brugerfladen.
Binding til workspacet. Domæner og indstillinger er kun tilgængelige for medlemmer af workspacet. For hver kontrol opretter Tjenesten en rapport under et tilfældigt link, der ikke kan gættes; resultaterne og skærmbillederne af en kontrol kan tilgås via dette link uden login, skærmbilleder kun sammen med linket til deres rapport. Linket vises på kontoen og i alarmer; den, der videregiver det, videregiver rapporten.
Tilstandsændrende forespørgsler kræver et sikkerhedstoken pr. session (CSRF-beskyttelse), som sammenlignes i konstant tid.
»Se som kunde«. Til support kan operatøren se applikationen, som en Kunde ser den. Visningen ophører efter en time, blokerer ændringer af adgangskode, adresse, anden faktor, enheder, abonnement, eksport og sletning, lukker administrationsområdet i mellemtiden og logføres. Når visningen afsluttes, logges operatøren helt ud; operatøren kan kun vende tilbage til administrationsområdet ved at logge ind igen med adgangskode og anden faktor. Kunden kan se det i sin dataeksport.
Administration. Kun få udtrykkeligt autoriserede konti har administrative rettigheder; enhver nulstilling af en anden faktor foretaget af administrationen logføres.

3.5 Adskillelseskontrol

Kundernes data er logisk adskilt efter workspace. Alle læse- og skriveveje i det indloggede område bærer denne binding med sig; rapporter er desuden tilgængelige via deres link (afsnit 3.4).
Udvikling og drift kører i separate installationer med separate databaser og separate databasebrugere. Udviklingsbrugeren har ingen adgang til produktionsdatabasen. Reelle kundedata kopieres ikke ind i udviklingsmiljøet; der arbejder vi med genererede eksempeldata.
For hvert miljø har scanneren sine egne loginoplysninger med rettigheder kun til de data, den har brug for til sine jobs. Den kan ikke læse konti, fakturering eller logfiler.
Andre tjenester fra samme udbyder kører også på webserveren. De har deres egne databaser og egne databasebrugere uden adgang til denne tjenestes data.

4. Kryptering, pseudonymisering og dataminimering

4.1 Loginoplysninger til scanningen bag login

Til denne funktion gemmer Kunden brugernavn og adgangskode til en testkonto. De er de mest følsomme data i tjenesten og beskyttes derfor anderledes end alt andet:

Ved lagring krypterer webserveren dem med scanningsserverens offentlige nøgle (ECIES: X25519 med en engangsnøgle pr. post, HKDF-SHA256, AES-256-GCM). Den private nøgle findes kun på scanningsserveren. Webserver, database og sikkerhedskopier indeholder kun ciffertekst; heller ikke vi kan læse den der.
Hver post er kryptografisk bundet til sit domæne. Flyttes den til et andet domæne, mislykkes dekrypteringen.
Ved en scanning vedhæftes cifferteksten jobbet. Scanningsserveren dekrypterer den og giver kun loginoplysningerne videre til kontrolcontaineren via standardinput, aldrig som kommandolinjeargument, der ville være synligt i proceslister. Så snart scanningsserveren har læst den, slettes cifferteksten fra jobbet; en kørsel rydder eventuelle rester op senest efter en time.
Loginoplysningerne vises aldrig, logges aldrig, udleveres aldrig via API'et og eksporteres ikke. Brugerfladen viser kun brugernavnets første tegn og længde. Fjernelse overskriver cifferteksten.
Bag login læser scanneren kun: ingen indsendelse, ingen aktiv test, ingen skærmbilleder, ingen sider til logout, sletning eller opsigelse.

4.2 Yderligere kryptering og hashes

Adgangskoder, gendannelseskoder, adgangskoder til kundeportaler, API-nøgler, forbindelses- og udrulningskoder, »Forbliv logget ind«-tokens, sessions-ID'er i enhedslisten og links til bekræftelse og nulstilling gemmes kun som hash.
Hemmeligheder til anden faktor gemmes krypteret (afsnit 3.2).
Vi hævder ikke, at hele databasen er krypteret i hvile. De følsomme værdier er beskyttet enkeltvis som beskrevet ovenfor.

4.3 Dataminimering gennem design

Leveringskontrol: Kun headerne og højst de første 8 KB af teksten læses. Kun tidspunktet, tilknytningen, i givet fald testindsendelsens ID og resultatet af ægthedskontrollen (SPF, DKIM, DMARC) havner i databasen, aldrig indholdet eller en fuld afsenderadresse. Ægthedsresultatet for den seneste e-mail opbevares ved domænet og overskrives af det næste; det indeholder IP-adressen på den leverende mailserver og afsenderens e-maildomæne. E-mailen slettes fra postkassen efter vellykket behandling; hvis hentning eller sletning mislykkes, sker det ved næste vellykkede kørsel.
Kontroller: Formularernes struktur gemmes med feltnavne, typer og etiketter, attributter for obligatoriske felter og synlighed, ingen værdier; scanneren læser begyndelsen af forudfyldte skjulte felter (op til 24 tegn) og af data-attributter (op til 60 tegn) kun under kontrollen og gemmer dem ikke. Skærmbillederne fra den fulde kontrol er ikke sløret; kun browserkontrollerne tildækker inputfelter. Modtageradresser i formularer gemmes kun som domæne. Aktive testindsendelser indeholder kun mærkede testtekster uden personoplysninger.
Udvidelser til WordPress og TYPO3 overfører kun daglige tal og kendetegn som plugin-oversigten og for et tilsluttet WordPress-plugin desuden domænerne for links fra blokerede beskeder til sværmbeskyttelse (slået til som standard); intet andet indhold, ingen navne, adresser eller IP-adresser på besøgende. Valgfrie tællinger af formular- og feltfejl er slået fra som standard.
»Fix it for me«: Den indsatte kode behandles kun i forespørgslens varighed og gemmes ikke.
Badge: Badgebilledet på kunders websites sætter ingen cookie og starter ingen session.
Driftsnotifikationer til operatørens telefon er faste tekster uden variabler, dvs. uden navne, adresser eller indhold. Fejlnotifikationer pr. e-mail til operatøren indeholder fejlmeddelelsens rå tekst, ikke renset og afkortet til 400 tegn; i enkelte tilfælde kan den indeholde adresser eller links.
Sværmbeskyttelse: Mellem Kundernes udvidelser deles kun domæner fra links i blokeret spam; udvekslingen af IP-netværk er slået fra.
Placering: Landet for en IP-adresse bestemmes ud fra en lokal databasefil; ingen adresse sendes til en geolokaliseringstjeneste.

5. Beskyttelse mod misbrug af scanneren

Scanneren indlæser tredjeparters sider med en rigtig browser. Uden beskyttelse ville den være et værktøj, hvormed nogen udefra kunne nå vores interne netværk eller andre ikke-offentlige mål (server-side request forgery). Derfor er der to uafhængige lag og isolering af hver enkelt kørsel.

5.1 Isoleret kørsel

Hver kontrol kører i sin egen container, som fjernes bagefter. Den kører uden administratorrettigheder, uden ekstra styresystemfunktioner (capabilities) og uden mulighed for at eskalere rettigheder. Dens filsystem er skrivebeskyttet bortset fra små flygtige områder.
Hukommelse, antal processer og kørselstid er begrænset; en kørsel, der overskrider tiden, afbrydes.

5.2 Netværk: to lag

Første lag, i scanneren: Før scanningen og derefter for hver enkelt forespørgsel fra browseren, inklusive omdirigeringer og indlejret indhold, kontrolleres det, hvortil adressen opløses. Private, lokale, reserverede og dokumentationsnetværk (IPv4 og IPv6) afvises, ligesom andre porte end dem, der er almindelige på nettet. Browseren tillader ikke service workers, og WebSocket-forbindelser lukkes, fordi begge kunne omgå denne kontrol.
Andet lag, i netværket: Containerne kører i deres eget netværk. Firewallregler tillader herfra kun forbindelser til internettet på webporte; forbindelser ind i private netværk, herunder vores interne netværk med webserver og database, er blokeret. Undtagelser, som kontrolkørslen selv kræver, er begrænset til det nødvendige og beskrevet i vores interne dokumentation. Dette lag virker også, hvis et navn først opløses anderledes efter den første kontrol.

5.3 Forespørgsler fra webserveren

Hvor webserveren selv forespørger tredjeparters adresser – til dokumentation for kontrol over domænet, til header-værktøjet, til søgningen efter eksponerede filer, til pulsforespørgsler, til RDAP-forespørgsler og til kontrol af certifikater, til webhooks og chatalarmer og til det valgfrie andet kontrolpunkt – gælder de samme regler: kun webprotokoller på de almindelige webporte (webhooks og chatalarmer kun via HTTPS på standardporten), kun offentlige adresser, kun forbindelse til præcis den adresse, der er kontrolleret forinden, så et navn ikke efterfølgende kan omdirigeres til et internt mål, omdirigeringer enten slet ikke fulgt eller kun fulgt manuelt og kontrolleret igen hver gang, korte tidsgrænser; for dokumentation for kontrol over domænet, for pulsforespørgsler og for det andet kontrolpunkt i browserkontroller desuden en begrænset svarstørrelse.

5.4 Hvad scanneren ikke gør på tredjeparters sites

Aktive testindsendelser (højst fem pr. kontrol) findes for Kunder kun for domæner, for hvilke der er dokumenteret kontrol (DNS, metatag, fil eller udvidelse); den eneste undtagelse er interne kontroller af vores egne test- og demodomæner. Værtsnavnet for et domæne med dokumenteret kontrol kan ikke ændres, så dokumentationen ikke overgår til en anden host. Alt andet er passivt: læsning af sider som en besøgende.
Browserkontroller går frem til punktet før indsendelse og udløser ingen bestilling, betaling eller indsendelse.
Domæner på opt-out-listen kontrolleres ikke; løbende overvågning ophører ved den næste planlagte kontrol.

6. Integritet: overførsel og input

6.1 Transport

Applikationen kan kun nås fra internettet via HTTPS; browseren instrueres i kun at bruge HTTPS i et år (HSTS). Certifikater fornyes automatisk.
Yderligere headers begrænser indlejring af applikationen i tredjeparters sider, gætning af filtyper og indsendelse af formularer til tredjeparters mål. En indholdssikkerhedspolitik (Content Security Policy) lader kun de scripts køre i applikationen, som serveren frigiver med det pågældende svar; aktuelle browsere udfører ikke indsprøjtede scripts eller event handlers i HTML'en.
Postkassen til leveringskontrollen hentes via en krypteret forbindelse med certifikatverifikation.
Webhooks kan signeres med en hemmelighed fra Kunden (HMAC-SHA256 med tidsstempel), så modtageren kan verificere oprindelse og integritet. Forespørgsler til det valgfrie andet kontrolpunkt signeres, og for browserkontroller også deres svar.
Åbent sagt: Forbindelser inden for vores interne netværk er ikke krypteret hele vejen igennem. Loginoplysningerne til scanningen bag login forbliver krypteret hele vejen igennem (afsnit 4.1).

6.2 Inputkontrol og logfiler

Vigtige handlinger på konti og i workspaces (såsom login, ændringer af domæner, alarmmodtagere og rettigheder, sletninger, supportadgang) registreres i aktivitetsloggen med konto, tidspunkt, IP-adresse og land og slettes efter 365 dage.
Sideadgangsregistreringer, der føres af hensyn til sikkerhed og forebyggelse af misbrug, slettes efter 60 dage, fejllogs efter 90 dage, indholdet af sendte e-mails efter 30 dage. Adgangstokens i forespurgte adresser og referrere, såsom tokens i rapport- eller portallinks, vises kun maskeret i sideadgangsregistreringerne.
Accept af aftaledokumenterne gemmes med den viste version, dens kontrolsum, tidspunkt, IP-adresse og browseridentifikator.
Dokumentationslogs kan forsynes med et tidsstempel fra en ekstern tidsstemplingsmyndighed; kun en kontrolsum af indholdet sendes dertil, ikke selve indholdet.

7. Tilgængelighed og robusthed

7.1 Sikkerhedskopiering

Databasen sikkerhedskopieres hver nat. En sikkerhedskopi får først sit endelige navn, efter at indholdet er kontrolleret: vellykket afslutning af sikkerhedskopieringsprogrammet, mindst én post, lige så mange tabeller, som databasen har, og den afsluttende linje fra en fuldstændig kørsel. Ældre sikkerhedskopier fjernes først efter en vellykket ny.
Hver sikkerhedskopi slettes efter 14 dage. Lagerplaceringen er uden for enhver leveret mappe; en placering inden for projektet afvises.
Gendannelsestest: Én gang om ugen indlæses den seneste sikkerhedskopi i en engangsdatabase, sammenlignes tabel for tabel med produktionen og slettes igen. Resultatet gemmes.
Hvis en sikkerhedskopi eller en test mislykkes, sendes en notifikation pr. e-mail og til operatørens telefon.
Genopretning efter en hændelse: Hvis databasen svigter, eller data bliver beskadiget, gendanner vi den seneste testede sikkerhedskopi. Ændringer foretaget siden denne sikkerhedskopi, som regel højst én dags ændringer, kan gå tabt i den forbindelse; hvis en sikkerhedskopiering er mislykkedes, tilsvarende flere. Derefter genudfører vi kendte senere sletningsanmodninger (afsnit 8). Vi forpligter os ikke til en bestemt genopretningstid.
Begrænsning, åbent sagt: Sikkerhedskopierne opbevares i øjeblikket samme sted som databasen og er ikke separat krypteret. De beskytter mod betjeningsfejl, fejlagtige ændringer og beskadigede data, ikke mod tab af selve serveren. En krypteret kopi på en anden placering er planlagt (afsnit 10).
Loginoplysningerne til scanningen bag login er kun indeholdt i sikkerhedskopierne som ciffertekst; hemmeligheden til anden faktor kun i krypteret form med en nøgle uden for databasen.

7.2 Overvågning

En statuskørsel kontrollerer tjenestens komponenter hvert femte minut, herunder databasen, køen og scannerens heartbeat, som scanneren skriver regelmæssigt, også når den er inaktiv. Hvis en komponent svigter, sendes en notifikation; når den kommer sig, en afblæsning.
Gensidig overvågning: En statuskørsel kan ikke rapportere svigt af den maskine, den selv kører på. Scanningsserveren kontrollerer derfor hvert minut, om applikationen svarer, og melder efter flere svigt i træk med en fast tekst til operatørens telefon. Omvendt overvåger webserveren scannerens heartbeat; opsætningstjeklisten viser, om den gensidige overvågning kører.
Fejlalarm: En fejltype, der aldrig er forekommet før, rapporteres straks én gang; en ophobning af fejl udløser kun et enkelt signal til operatørens telefon; én gang om dagen sendes en oversigt. Det betyder, at vi ikke først hører om en fejl fra en Kunde.
Begrænsning, åbent sagt: Begge servere står samme sted. Et svigt af hele placeringen, f.eks. af strøm eller internetforbindelse, rapporteres ikke af nogen alarmmekanisme, men opdages af et menneske.

7.3 Ændringer og udrulning

Nye versioner bygges og testes først i det separate udviklingsmiljø. Udrulningen kontrollerer alle forudsætninger, før den første fil skrives, gennemfører ændringerne af databaseskemaet og lader igangværende kontroller afslutte ordnet, før scanneren genstarter.
For en ny Kundes forløb findes en røgtest over rigtig HTTP, som køres efter omstillinger. Vi hævder ikke, at en automatiseret testsuite kører før hver eneste udrulning.

8. Sletning og opbevaringsperioder

En sletningskørsel hver nat håndhæver de perioder, der er angivet i privatlivspolitikken og databehandleraftalen. Den læser de samme indstillinger, som tallene i teksterne er hentet fra; for disse perioder afviger tekst og adfærd derfor ikke fra hinanden.
Kontrolresultater inklusive skærmbilleder slettes efter 13 måneder (det seneste pr. domæne bevares), tal fra udvidelser efter 13 måneder, leveringslogs for alarmer efter 90 dage, supportanmodninger efter 24 måneder.
Fjernelse af et domæne sletter domænets data, herunder kontroller, formularer, fund, skærmbilleder, rapporter, jobs, alarmmodtagere og -logs, hændelser, leveringsdata, loginoplysninger til scanningen bag login og dokumentation.
Sletning af en konto sker straks; workspaces uden yderligere medlemmer slettes med deres data, workspaces med yderligere medlemmer overgår til et andet medlem, først til administratorer og blandt dem til det medlem, der har været med længst. Indtil deres egne perioder udløber, bevares følgende: de logfiler, hvis poster beholder det gamle kontonummer, som ikke længere henviser til nogen eksisterende konto, herunder sletningsposten, samt sendte e-mails, dokumentationen for aftaleindgåelsen, supportanmodninger, rapporter fra kontroller af potentielle kunder (op til 90 dage) og faktureringsdata hos Stripe; detaljer findes i privatlivspolitikken.
Slettede data forbliver i sikkerhedskopier, indtil disse udløber efter 14 dage. Målrettet sletning inden for en sikkerhedskopi finder ikke sted; hvis en sikkerhedskopi gendannes, udføres kendte senere sletningsanmodninger igen manuelt.

9. Organisation og gennemgang

Personer: Tjenesten drives i øjeblikket af ejeren selv. Yderligere personer får kun adgang efter en fortrolighedserklæring og kun i det nødvendige omfang, og de behandler kun data efter vores instruks (art. 29 og art. 32(4) GDPR).
Underdatabehandlere: Vi gør kun brug af dem efter gennemgang af deres garantier og i henhold til en aftale efter art. 28(4) GDPR og opfører dem på siden Underdatabehandlere; detaljer reguleres af databehandleraftalen.
Brud på persondatasikkerheden: Hvis et brud på persondatasikkerheden berører databehandlerdata, underretter vi Kunden uden unødig forsinkelse, så vidt muligt inden for 48 timer; detaljer reguleres af databehandleraftalen.
Indberetning af sårbarheder: Vi modtager indberetninger på Sikkerhed og via filen /.well-known/security.txt.
Opsætnings- og lanceringstjekliste: I administrationsområdet måler en tjekliste tilstanden af sikkerhedsrelevante indstillinger, såsom sikkerhedskopiering, administratorer uden anden faktor, mailopsætning og heartbeat, og viser afvigelser.
Gennemgang af disse foranstaltninger (art. 32(1)(d) GDPR): ved enhver væsentlig ændring af tjenesten, efter enhver sikkerhedshændelse og i øvrigt mindst én gang om året. Vi vurderer i den forbindelse, om foranstaltningerne er effektive og stadig svarer til risiciene, og registrerer resultatet i en ny version af denne side eller, hvis intet ændres, med datoen for gennemgangen i afsnit 11. Løbende måler opsætnings- og lanceringstjeklisten tilstanden af de indstillinger, den omfatter.
Eksterne audits: Der er i øjeblikket ikke bestilt eksterne penetrationstest, og der findes ingen sikkerhedscertificeringer. Det er angivet her, så ingen antager, at de findes.

10. Planlagt, endnu ikke gennemført

Disse punkter er ikke foranstaltninger, vi forpligter os til, før de er opført her som gennemført i en ny version:

Sikkerhedskopi på en anden placering: en krypteret kopi af den natlige sikkerhedskopi uden for serveren, så selv et totalt tab af serveren ikke fører til datatab.
Andet kontrolpunkt: Uafhængig bekræftelse af browserkontroller fra en anden placering er forberedt i tjenesten, men ikke sat op. Uden den er der ingen bekræftelse fra en anden placering.
Hærdning af serveradministrationen: Dette arbejde fortsætter. Af de grunde, der er angivet i afsnit 1, offentliggør vi ikke detaljer.

11. Status og version

Version 1.1 · Senest opdateret: 22. oktober 2026 · i tilfælde af uoverensstemmelser mellem sprogversionerne har den polske version forrang i stedet for den tyske; ingen anden ændring.
Version 1.0 · Senest opdateret: 11. oktober 2026 · første version som separat side; tidligere bilag 2 til databehandleraftalen. Rettet i forhold til det tidligere bilag: gendannelsestesten kører ugentligt, sikkerhedskopierne ligger på samme server, der kører ingen automatiseret testsuite før hver udrulning, forbindelser i det interne netværk er ikke krypteret hele vejen igennem. Nyt beskrevet: kryptering af loginoplysningerne til scanningen bag login, isolering af scanneren, gensidig overvågning og fejlalarm.
Ændringer offentliggøres med nyt versionsnummer her og i oversigten Ændringer af aftaledokumenterne; ved enhver svækkelse af foranstaltninger gælder varslet i databehandleraftalen.
I tilfælde af uoverensstemmelser mellem sprogversionerne har den polske version forrang.

Hvordan kan vi hjælpe?