Dette dokument er offentliggjort på flere sprog. I tilfælde af uoverensstemmelser mellem sprogversionerne er den polske version bindende.
Version 1.2 · Senest opdateret: 29. oktober 2026
1. Sådan skal denne fortegnelse læses
Dette er fortegnelsen over behandlingsaktiviteter efter art. 30 GDPR for formexposed. Den er ikke en privatlivspolitik og ikke markedsføring. Dens opgave er at vise en tilsynsmyndighed, en Kunde, der auditerer os som databehandler, eller den næste person, der skal besvare et spørgsmål, hvad der faktisk behandles, hvor det opbevares, hvem der modtager det, og hvor længe det bliver. Vi offentliggør den, fordi en tjeneste, der kontrollerer og overvåger formularer, selv bør kunne kontrolleres.
Tre regler har styret, hvordan den er skrevet.
- Målt, ikke tilsigtet. En angivelse af datafelter, opbevaringsperioder, modtagere eller garantier optræder kun, hvor programkoden, databaseskemaet eller en måling understøtter den. Det, der er planlagt, kaldes »planlagt«. Det, der er slået fra som standard, kaldes »slået fra som standard«. Hvor vi ikke kan bevise noget, siger vi det.
- Opbevaring angives to gange. Én gang for hver behandlingsaktivitet og én gang i afsnit 6 som det samlede billede: hvilken natlig kørsel der sletter hvilke data, og hvilke data den ikke når. En fortegnelse, der hævder en opbevaringsperiode, som kun gælder for en del af dataene, er værre end en, der nævner det åbne punkt.
- Åbne punkter angives i teksten, ikke i en fodnote. Afsnit 8.1 opfører foranstaltninger, der endnu ikke er gennemført, afsnit 10 de åbne punkter med de planlagte foranstaltninger. En fortegnelse er et arbejdsredskab, ikke et certifikat.
Datafelter i stedet for tabelnavne. For hver behandlingsaktivitet opfører vi de gemte data som felter i almindeligt sprog. Navnet på databasetabellen følger i parentes, så en revisor kan finde stedet, f.eks. »loginforsøg (login_attempts)«. Feltlisterne er udledt af databaseskemaet, ikke skrevet efter hukommelsen.
Opbevaringsperioder som pladsholdere. Hvor en opbevaringsperiode kan indstilles i administrationsområdet, vises den her præcis, som den natlige kørsel læser den: Det tal, du ser, kommer fra den samme indstilling, der styrer sletningen. Opbevaringsperioder, der er fastlagt i programmet, angives som tal.
Målegrundlag. Skema, kode og indstillinger blev målt den 11. oktober 2026 på udviklingssystemet, som i kode og skema svarer til produktionssystemet. Vi angiver ikke antal rækker fra udviklingssystemet; de indeholder testdata og siger intet om den faktiske drift.
Bevidst udeladt. Denne fortegnelse nævner ikke værtsnavne, interne netværksadresser, porte, brugernavne eller softwareversioner for vores servere. Sådanne detaljer hjælper en angriber og ingen registreret. Af samme grund beskriver vi kun åbne punkter i sikringen af vores egne servere i generelle vendinger (afsnit 8.1): Vi nævner risikoen, ikke vejen dertil. Vi giver detaljerne til en tilsynsmyndighed efter anmodning.
Retlig karakter. Denne fortegnelse er den dokumentation, vi fører efter art. 30 GDPR for tilsynsmyndigheden; den offentliggøres frivilligt. Den udgør ikke en del af nogen aftale og udgør ingen tilsikring, garanti eller aftale om kvalitet over for Kunder eller tredjeparter. Hvad vi skylder Kunder, reguleres af servicevilkårene, databehandleraftalen og dens bilag; med hensyn til disse forpligtelser har de forrang for denne fortegnelse. Fortegnelsen beskriver situationen på datoen for denne version. Klassificeringer som »åbent punkt« eller »vurdering« afspejler vores egen opfattelse og foregriber ikke en retlig vurdering foretaget af en tilsynsmyndighed eller en domstol; foranstaltninger, der beskrives som »planlagt«, er hensigter uden en bindende dato.
2. Den juridiske enhed, og hvorfor denne fortegnelse har to halvdele
| Felt | Angivelse |
| Juridisk enhed | LW IT Solutions Company Lukas Wójcik, enkeltmandsvirksomhed registreret i det polske erhvervsregister (CEIDG); ejer Lukas Wójcik |
| Adresse | al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen |
| Skatteidentifikatorer | NIP 7252266190, momsnummer PL7252266190 |
| Kontakt | contact@lukaswojcik.com; supportvinduet (spørgsmålstegnet i navigationen); kontaktsiden |
| Tjeneste | formexposed: kontrol, overvågning og sikring af kontaktformularer på websites (app på formexposed.com, landingsside på form.exposed) |
| Repræsentant efter art. 27 GDPR | Ikke relevant. Den juridiske enhed er etableret i Unionen (Polen). |
| Databeskyttelsesrådgiver | Ikke udpeget. Vurderingen efter art. 37 findes i afsnit 9. |
| Kompetent tilsynsmyndighed | Prezes Urzędu Ochrony Danych Osobowych (UODO, den polske databeskyttelsesmyndighed), ul. Moniuszki 1A, 00-014 Warszawa |
| Hosting | Vores egne servere i Polen: én webserver med applikationen og databasen og én scanningsserver med en lokal sprogmodel i samme interne netværk. Intet tredjepartsdatacenter og ingen cloududbyder. |
formexposed spiller forskellige roller over for forskellige grupper af personer. Blandes de sammen, opstår der en fortegnelse, der ikke er rigtig for nogen af dem.
- Dataansvarlig (del B, art. 30(1)). Vi er selv dataansvarlige for data om vores egne Kunder og deres teammedlemmer (konto, login, fakturering, support, logfiler), for besøgende på vores eget website, for kontroller uden konto (gratis kontrol, header-værktøj, undersøgelse, kontrol af potentielle kunder) og for forebyggelse af misbrug.
- Databehandler (del A, art. 30(2)). For personoplysninger om tredjeparter, som en Kunde bringer ind i tjenesten, eller som opstår, når vi udfører en ydelse for Kunden, handler vi på Kundens vegne: kopier af ægte formular-e-mails i leveringskontrollen, abonnenter på Kundens kundeportal, modtagere af Kundens alarmer, personer, der tilfældigvis er synlige på Kundens kontrollerede sider, loginoplysningerne til Kundens testkonto og den formularkode, som Kunden indsætter. Grundlaget er databehandleraftalen, som indgås med enhver Kunde ved registreringen.
- Kun på Kundens side. Nogle funktioner i WordPress-pluginnet og TYPO3-udvidelsen behandler data udelukkende på Kundens website, uden at dataene nogensinde når os (karantæne, sikkerhedsnet, regneopgave, indstillinger for opbevaring, lokale tællere, optager). De er ikke behandling foretaget af os og optræder derfor i ingen af delene. Vi beskriver dem alligevel i slutningen af del A, så grænsen er synlig.
Adskillelsen er indbygget i koden, ikke kun i teksten: Fra en ægte formular-e-mail skriver leveringskontrollen kun tidspunktet, tilknytningen og autentificeringsresultatet i databasen; skærmbillederne fra browserkontrollerne maskerer inputfelter; testkontoens loginoplysninger krypteres på en sådan måde, at webserveren ikke længere kan læse dem. Detaljerne fremgår af posterne.
Afsnit 6 til 11 gælder for begge halvdele: opbevaring, automatiske afgørelser, tekniske og organisatoriske foranstaltninger, databeskyttelsesrådgiver, åbne punkter og vedligeholdelsen af denne fortegnelse.
Omfang. Dette dokument er den del af fortegnelsen, der vedrører tjenesten formexposed. Behandling, som den samme juridiske enhed foretager for andre tjenester, registreres i deres egne fortegnelser; generel bogføring og virksomhedsadministration uden for tjenesten er ikke omfattet af denne del.
3. Del A – art. 30(2): behandling på vegne af Kunder
A.0 Involverede parter
| Felt | Angivelse |
| Databehandler | LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen; contact@lukaswojcik.com |
| Dataansvarlige | Kunderne hos formexposed: virksomheder og bureauer, der har domæner på deres konto og bruger funktioner, hvor der opstår tredjepartsdata. Hos bureauer kan bureauets egen kunde desuden være dataansvarlig; bureauet er da databehandler over for denne kunde, og vi er yderligere databehandler. |
| Liste over dataansvarlige | Del af denne fortegnelse, ført i elektronisk form (art. 30(3) GDPR) i tjenestens system og ikke gengivet i denne offentlige version, fordi den indeholder personoplysninger om Kunder og ville være forældet ved hver ny Kunde: ejeren af hvert workspace med navn, e-mailadresse og virksomhed fra kundekontoen (adresse og momsnummer kun hos Stripe) (users, workspaces, workspace_users) samt workspacets domæner (domains). Vi giver den til en tilsynsmyndighed som udtræk efter anmodning. |
| De dataansvarliges repræsentanter og databeskyttelsesrådgivere | Der er intet særskilt felt til dette i systemet. Hvis en Kunde har udpeget en repræsentant efter art. 27 GDPR eller en databeskyttelsesrådgiver, kan Kunden meddele os det; vi opbevarer meddelelsen sammen med listen over dataansvarlige. |
| Databehandlerens repræsentant | Ikke relevant (etableret i Polen). |
| Databeskyttelsesrådgiver | Ikke udpeget (afsnit 9). |
| Instrukser | Instruksen følger af databehandleraftalen og af de indstillinger, Kunden foretager: Kunden slår leveringskontrollen til, opretter alarmmodtagere, gemmer en testkonto og opretter en kundeportal. Uden denne handling finder den pågældende behandling ikke sted. |
| Tekniske og organisatoriske foranstaltninger | Afsnit 8 og siden Tekniske og organisatoriske foranstaltninger gælder for alle behandlingsaktiviteter i del A. Særlige foranstaltninger er angivet i den relevante post. |
A.1 Leveringskontrol – kontrolkopi af formular-e-mails
| Felt | Angivelse |
| Formål | Kontrol af, om e-mailen fra Kundens kontaktformular faktisk sendes, og hvordan den autentificeres (SPF, DKIM, DMARC, alignment). Efter en accepteret aktiv testindsendelse skal dens kopi ankomme i kontrolpostkassen inden for en justerbar ventetid (i øjeblikket 3 timer); ellers udløses alarmen »Test-e-mail ikke modtaget«. Headerne bruges også til at udlede formular-e-mailens ægthed, den anvendte e-mailtjeneste og afsenderadressen til kontrollen af blokeringslister. |
| Forudsætning | Betalt abonnement, verificeret domæne, slået til af Kunden. Kunden indsætter sin egen kontroladresse med en identifikator (af formen »delivery+identifikator@…«) som blindkopi i sin formulars notifikation. Uden en konfigureret kontrolpostkasse er funktionen ikke tilgængelig. |
| Kategorier af registrerede | Besøgende på Kundens website, der indsender Kundens formular; personer, hvis data en besøgende skriver i beskeden; Kundens medarbejdere, der optræder som modtagere i headerne. |
| Kategorier af personoplysninger | I kontrolpostkassen (hos mailtjenesteudbyderen): den fuldstændige kopi af hver formular-e-mail, herunder ægte henvendelser med navn, e-mailadresse, telefonnummer og fritekst, indtil sletning. Læst af hentningen: headerne og højst de første 8 KB af brødteksten. I databasen: modtagelsestidspunkt, tilknytning til domænet og i givet fald til testkørslen (delivery_log); det seneste autentificeringsresultat pr. domæne med SPF-, DKIM- og DMARC-resultat, alignment, afsenderdomæne, signerende domæner og adressen på den afsendende mailserver (autentificeringsfeltet for domænet i domains). Indhold, emne og den besøgendes afsenderadresse skrives ikke i databasen. |
| Bemærkning om afsenderdomænet | Hvis en formular indsætter den besøgendes adresse som afsender (en fejlkonfiguration, som kontrollen er udformet til at afdække), indeholder autentificeringsresultatet domænet for denne adresse, ikke selve adressen. Hvis en besøgende bruger et personligt domæne, kan også dette være en personoplysning. Det overskrives ved næste modtagelse. |
| Kilde | Formularen på Kundens website via den blindkopi, Kunden har indsat. |
| Retsgrundlag (fastlagt af den dataansvarlige) | Fastlægges af Kunden. Vores tekstforslag til Kundens privatlivspolitik baserer kopien på art. 6(1)(f) GDPR (legitim interesse i pålideligt at modtage henvendelser). Kunden oplyser sine besøgende om denne datastrøm; databehandleraftalen forpligter Kunden hertil. |
| Modtagere | Den mailtjenesteudbyder, der driver kontrolpostkassen (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). Kopien går direkte dertil: Den ankommer kun, hvis MX-posterne for vores domæne peger på denne postkasse (tjeklisten før lanceringen kontrollerer dette); via en videresendelse når den ikke postkassen. På domænesiden ser Kunden kun tidspunkt, tilknytning og autentificeringsresultat. Hvis autentificeringsresultatet forringes, nævner alarmen til Kunden og til de kanaler, Kunden har valgt, afsenderdomænet, hvis det ikke hører til websitet (A.3, 4.1). |
| Tredjeland | Afhænger af mailtjenesteudbyderen; se afsnit 4. Aftalen med den påtænkte udbyder og overførselsgrundlaget er endnu ikke dokumenteret. |
| Opbevaring | Efter vellykket behandling markeres e-mailen til sletning og fjernes fra postkassen i samme kørsel, også selv om den ikke kan knyttes til noget domæne. Hentningen kører med statuskørslen hvert femte minut, mens overvågningen er slået til i administrationsområdet (srv/cron_status.php, cfg/zustellung_lib.php). Hvis hentning eller sletning mislykkes, forbliver e-mailen i postkassen indtil næste vellykkede kørsel. Samme hentning sletter tilknytningerne i delivery_log efter 180 dage. Autentificeringsresultatet lever lige så længe som domænet. |
| Hvad dokumentationen beviser | Kun modtagelsen i kontrolpostkassen af den kopi, der er knyttet til den konkrete testkørsel. Den beviser hverken modtagelse hos den egentlige modtager eller en registrering i CRM'et. Indbygget bekræftelse fra HubSpot tilbydes ikke. |
| TOM'er | Afsnit 8. Navnlig: Indhold evalueres kun i hukommelsen; ingen lagring af brødtekst, emne eller fulde afsenderadresser; sletning uanset om tilknytningen lykkedes. |
Leveringskontrollen er den eneste funktion, hvorigennem ægte beskeder fra vores Kunders besøgende når os. Derfor er den behandling på vegne af Kunden og ikke en ydelse under vores eget ansvar, og derfor er tiden i postkassen det reelle mål for risikoen: normalt minutter; hvis hentningen er forstyrret, indtil den kører igen. Kopier bør ikke indeholde særlige kategorier af personoplysninger; det kan vi ikke teknisk forhindre, for hvad en besøgende skriver, er op til den besøgende.
A.2 Kundeportal og månedlig rapport til abonnenter
| Felt | Angivelse |
| Formål | Et bureau (Business-abonnement) viser sine kunder tilstanden af deres domæner under sit eget brand (portal på en tilfældig adresse, valgfrit med adgangskode, valgfrit under et subdomæne af bureauets eget domæne). Kunden kan der bestille en månedlig rapport pr. e-mail. Rapporten sendes i bureauets navn. |
| Kategorier af registrerede | Bureauets kunder og deres medarbejdere, der bestiller rapporten; personer, der åbner portalen. |
| Kategorier af personoplysninger | Abonnent: e-mailadresse, sprog, bekræftelsesidentifikator, tidspunkt for bestillingen og IP-adresse på tidspunktet for bestillingen, tidspunkt for bekræftelse (double opt-in), tidspunkt for afmelding, senest sendte måned (client_subscribers). Portal: navn, udvalg af domæner, tilfældig identifikator, adgangskode kun som hash, person, der har oprettet den, tidspunkt, tilbagekaldelse (client_portals). Besøg på portalen fremgår af sidevisningsloggen (B.2). |
| Kilde | Indtastet af abonnenterne selv i portalen. |
| Retsgrundlag (fastlagt af den dataansvarlige) | Abonnentens samtykke, indhentet via en double opt-in-procedure; dataansvarlig er bureauet. Vi skriver ikke til nogen, der ikke selv har tilmeldt sig og bekræftet. |
| Modtagere | Bureauet (ser sine abonnenter); mailtjenesteudbyderen (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) til bekræftelses-e-mailen og rapporten. |
| Tredjeland | Via mailtjenesteudbyderen; se afsnit 4. |
| Opbevaring | Natlig sletningskørsel (cfg/fristen_lib.php, delen »portalabonnenter«): aldrig bekræftede bestillinger efter 30 dage; afmeldte abonnenter tre år efter afmeldingen som dokumentation for det tidligere samtykke. Bekræftede abonnenter, der ikke har afmeldt sig, forbliver, så længe bureauets workspace eksisterer. En tilbagekaldt portal blokeres kun, den slettes ikke; dens abonnenter modtager ikke længere rapporter, men deres data forbliver (afsnit 10). Portaler og abonnenter forsvinder straks sammen med workspacet (fe_arbeitsbereich_daten_loeschen()). Sendte rapporter forbliver i udbakken i 30 dage (B.25). |
| TOM'er | Afsnit 8. Navnlig: portaladgangskode kun som hash, gætteforsøg begrænset (ti pr. portal og IP-adresse, 50 pr. portal på 15 minutter); afmelding med ét klik i hver e-mail; portalen viser kun status og nøgletal, ingen enkelte fund med dokumentation. |
A.3 Kundens alarmmodtagere, kvitterende personer og ansvarlige
| Felt | Angivelse |
| Formål | Notifikationer om fejl og ændringer til de modtagere, Kunden opretter for et domæne: e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Pr. modtager straks eller samlet dagligt eller ugentligt, plus modtagere kun til eskaleringer. Hver problemnotifikation bliver til en hændelse, som modtageren kan kvittere for via et link. For overvågede formularer kan Kunden angive en ansvarlig person og en forfaldsdato. |
| Kategorier af registrerede | Kundens medarbejdere og tjenesteudbydere, som Kunden indtaster som alarmmodtagere eller angiver som ansvarlige; personer, der kvitterer for en hændelse. Teammedlemmer med egen konto optræder også i del B. |
| Kategorier af personoplysninger | Alarmmodtager: kanal, modtageradresse (e-mailadresse, webhook- eller chatadresse, Telegram-chat-ID), valgte hændelser, leveringsmåde, signeringshemmelighed for webhooks, seneste levering og seneste fejl (alerts). Leveringslog: modtager, hændelser, status, fejl, tidspunkt (alert_log). Kø til sammendrag: notifikationslinjer og link indtil levering (alert_queue). Hændelse: titel, notifikationslinjer, link, kvitteringsidentifikator, tidspunkt og navn eller e-mailadresse på den kvitterende person som indtastet i formularen, ellers adressen på det indloggede medlem (alert_incidents). Eskaleringsleveringsforsøg pr. hændelse og modtager: antal forsøg (højst fem), tidspunkter for det seneste og det næste forsøg og for succes, henvisning til e-mailen i udbakken, fejl (tabellen alert_escalation_deliveries). Tildeling: den ansvarlige persons konto og forfaldsdato (i monitored_forms). |
| Notifikationernes indhold | Domæne, hændelse, en kort forklaring og et link til domænesiden. Intet indhold fra besøgendes beskeder. |
| Kilde | Indtastet af Kunden; den kvitterende person indtaster selv sit navn; Telegram-chat-ID'et oprettes, når modtageren trykker på »Start« i botten (B.32). |
| Retsgrundlag (fastlagt af den dataansvarlige) | Fastlægges af Kunden; som regel organisering af Kundens egen drift (art. 6(1)(b) eller (f) GDPR i forhold til Kundens medarbejdere og tjenesteudbydere). |
| Modtagere | Operatørerne af de valgte kanaler; se 4.1. E-mailalarmer via mailtjenesteudbyderen (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tredjeland | Afhængigt af den valgte kanal; flere udbydere har hjemsted i USA, Telegram uden for EU uden afgørelse om tilstrækkeligheden af beskyttelsesniveauet. Se 4.1. |
| Opbevaring | Leveringslog efter 90 dage (natligt, fe_alert_log_aufraeumen() fra srv/cron_status.php). Sammendragsnotifikationer 30 dage efter levering (cfg/kanal_lib.php, ved hver levering af sammendrag). Hændelser, mens de er uløste; løste hændelser 180 dage efter løsning (cfg/vorfall_lib.php, eskaleringskørsel), sammen med deres eskaleringsleveringsforsøg. Alarmmodtagere og tildelinger indtil sletning af Kunden eller sammen med domænet. |
| TOM'er | Afsnit 8. Navnlig: webhooks signeret med en separat hemmelighed pr. modtager; kvittering kun efter et klik (POST), så linkforhåndsvisninger i chatprogrammer ikke udløser noget; alarmer under et vedligeholdelsesvindue logges kun og sendes ikke. |
A.4 Personer, der tilfældigvis er synlige på kontrollerede kundesider og i skærmbilleder
| Felt | Angivelse |
| Formål | Kontrollen af domænerne på Kundens konto (scanning, overvågning, aktiv kontrol) læser Kundens offentlige sider og tager skærmbilleder af formularer. Det, som siden selv viser, kan vedrøre personer, der intet har med kontrollen at gøre. Disse data opstår tilfældigt; de er ikke formålet med kontrollen. |
| Kategorier af registrerede | Personer, hvis navn, foto eller kontaktoplysninger fremgår af den kontrollerede side (kontaktperson ved siden af formularen, teamfotos på forsiden, oplysninger i kolofonen). |
| Kategorier af personoplysninger | Skærmbilleder: det synlige område af forsiden, hver synlig formular som udsnit og billedet af den efterfølgende side efter en aktiv testindsendelse; gemt som filer uden for webmappen, med kun henvisningen i databasen (scan_screenshots). Formularstruktur: sideadresse, selektor, feltnavne, felttyper, feltetiketter, markeringer for obligatoriske felter og synlighed, etiketter på indsend-knapper (forms, feltet »feltkort«); ingen feltværdier. Scanneren læser begyndelsen af skjulte felter (op til 24 tegn) og data-attributter (op til 60 tegn) kun under kontrollen for at genkende tidsstempler og tokens; kun resultatet gemmes. Fund med dokumentation (findings), sammendrag med sidetitler (scans). Hvis en e-mailadresse fremgår af formularen som modtager, gemmes kun dens domæne, aldrig adressen. |
| Kilde | De offentlige sider på Kundens domæne, hentet af scanneren. |
| Retsgrundlag (fastlagt af den dataansvarlige) | Fastlægges af Kunden for indholdet af Kundens eget website. For os er behandlingen en del af den bestilte kontrol. |
| Modtagere | Kunden; hos bureauer deres kunde via portalen eller en white label-rapport; enhver, der modtager et rapportlink (rapporter på tilfældige adresser, ikke i søgemaskiner). Hvor formulartypen er uklar, modtager en lokal sprogmodel på vores egen server formularstrukturen med sidetitel, sideadresse og formularens synlige tekst (op til 400 tegn) til klassificering; den modtager ikke billeder. |
| Tredjeland | Intet. |
| Opbevaring | Kontrolresultater for et domæne i højst 13 måneder; den senest gennemførte kontrol pr. domæne bevares (natlig sletningskørsel, delen »gamle kontrolresultater«). Formularer, fund, billedhenvisninger og billedfilerne forsvinder sammen med kontrolresultatet. Sammen med domænet forsvinder disse data straks (sletningskæde i B.15; undtagelser i afsnit 6.4). |
| Grænser for maskeringen | Skærmbillederne fra den fulde kontrol maskerer intet: De viser, hvad siden viser enhver besøgende. Formularfelter er tomme ved hentningen, fordi scanneren ikke indtaster noget; forudfyldte værdier ville være synlige. Der tages ingen skærmbilleder bag et login (A.5). Billederne fra browserkontrollerne maskerer inputfelter (A.6). |
| TOM'er | Afsnit 8. Navnlig: Billeder kan kun hentes via rapporten, og en andens billedidentifikator giver »ikke fundet«; rapporter med noindex; hver kontrol kører i sin egen isolerede container. |
De samme data opstår ved kontroller uden konto (gratis kontrol, undersøgelse, kontrol af potentielle kunder). Der findes ingen Kunde, på hvis vegne vi handler; disse tilfælde optræder derfor i del B (B.5, B.7, B.8).
A.5 Testkontoens loginoplysninger til scanningen bag login
| Felt | Angivelse |
| Formål | Læsning af formularer, der først vises efter login (kundeområde, medlemsområde). Scanneren logger ind med en testkonto, som Kunden har oprettet på sit eget website, og læser de angivne sider. Bortset fra loginformularen indsender den intet, udfører ingen aktiv test der, tager ingen skærmbilleder og besøger ikke adresser til logout, sletning eller opsigelse. Hvis loginformularen har en CAPTCHA, stopper den; CAPTCHA'er omgås ikke. |
| Forudsætning | Verificeret domæne, betalt abonnement, rollen ejer eller administrator, udtrykkelig bekræftelse af, at kontoen er en testkonto. Højst fem sider, alle på samme domæne. |
| Kategorier af registrerede | Den person, i hvis navn testkontoen står (ideelt set ingen; Kunden bør bruge en funktionskonto); personer, hvis data fremgår af siderne bag login. |
| Kategorier af personoplysninger | Testkontoens brugernavn og adgangskode, kun krypteret; et hint om brugernavnet (første tegn og længde); login-adresse, liste over sider, navne på loginfelterne, succesindikator, person, der har oprettet den, tidspunkter, seneste resultat som kort kode (domain_logins). For et kørende job en kopi af cifferteksten (feltet »loginpakke« i scan_jobs). Fra siderne bag login: formularstruktur som i A.4, uden skærmbilleder og uden cookies. |
| Kilde | Indtastet af Kunden på kontoen. |
| Retsgrundlag (fastlagt af den dataansvarlige) | Fastlægges af Kunden. Kunden indestår for, at Kunden er berettiget til at bruge testkontoen. |
| Modtagere | Ingen. Hverken Kunden, supporten eller programmeringsgrænsefladen kan læse loginoplysningerne ud; grænsefladen viser kun hintet om brugernavnet. |
| Tredjeland | Intet. |
| Beskyttelse af loginoplysningerne | Brugernavn og adgangskode krypteres straks ved lagring med scanningsserverens offentlige nøgle (X25519, HKDF-SHA256, AES-256-GCM; domænet bindes som tilknyttede data, så en ciffertekst ikke kan knyttes til et andet domæne). Kun scanningsserveren har den private nøgle. Webserver, database og sikkerhedskopier indeholder kun ciffertekst; heller ikke vi kan dekryptere den der. Scanningsserveren dekrypterer kun til kørslen, giver kun loginoplysningerne videre til den isolerede kontrolcontainer via standardinput, sletter straks kopien i jobbet og skriver dem ikke i noget resultat, nogen log eller nogen fejltekst. På vejen til Kundens website er de kun beskyttet af dette websites kryptering; begrænsningerne ved denne transport fremgår af afsnit 10. |
| Opbevaring | Gemte loginoplysninger indtil sletning af Kunden. Ved sletning overskrives cifferteksten med tilfældige data af samme længde, og rækken slettes; ventende jobs ryddes (fe_login_loeschen()). Sammen med domænet forsvinder rækken via en fremmednøgle. Scanningsserveren rydder kopier i jobs efter kørslen; det, der er tilbage (job afbrudt, scanningsserver nede), ryddes af statuskørslen senest efter en time (fe_login_aufraeumen(), delen »login_jobs«). Databasesikkerhedskopier indeholder cifferteksten, indtil sikkerhedskopien udløber efter 14 dage. |
| TOM'er | Afsnit 8. Navnlig: asymmetrisk kryptering med separate nøgler; blokeringsliste for logout- og sletningsstier; ingen skærmbilleder bag login; funktion kun for betalte abonnementer og verificerede domæner; enhver ændring i aktivitetsloggen (uden loginoplysninger). |
Vi har bevidst ikke bygget nogen mulighed for at gemme loginoplysninger til Kundens server, CMS-administrationsområde eller hostingkonti. Testkontoen er en besøgendekonto på Kundens website, ikke adgang til Kundens system.
A.6 Konfigurerede formularforløb, browserkontroller og uafhængig probe
| Felt | Angivelse |
| Formål | En overvåget formular gennemløbes i en rigtig browser (Chromium, WebKit eller begge) frem til punktet lige før indsendelse: indlæs siden, udfør forudgående klik (højst fem, aldrig på et inputfelt eller en indsend-knap), udfyld felter med genkendeligt syntetiske værdier (såsom en adresse under den reserverede endelse .invalid), gå videre i flertrinsformularer. Browserkontrollen indsender intet; indsendelse er teknisk blokeret i browseren. Derudover tidsmålinger og visuelle sammenligninger af formularen. |
| Kategorier af registrerede | Som A.4 (personer, der er synlige på formularsiden); Kundens medarbejdere, der er angivet som ansvarlige (A.3). |
| Kategorier af personoplysninger | Konfiguration: formularadresse, selektorer, startadresse, kliktrin, browservalg, etiket, kritikalitet, tildeling, forfaldsdato (monitored_forms). Resultater pr. kørsel: tilstand, teknisk fejlårsag, rensede fejlmeddelelser, netværks- og tidsmålinger, et billede af formularen som JPEG på højst 32 KB med maskerede inputfelter (form_browser_runs). Observationer pr. kontrol (form_observations), tidsserier (form_performance). Jobs med en målliste (felterne »mål« og »resultat« i scan_jobs). |
| Testadgang | Hvis Kunden har gemt en testkonto (A.5), bruger den fulde kontrol den også til konfigurerede formularforløb. Ifølge den målte kode fungerer de selvstændige browserkontroller mellem to fulde kontroller uden testkonto. |
| Uafhængig probe | Et andet kontrolpunkt på en anden placering er forudset, som ville krydstjekke før en alarm. Det ville modtage domænet, den rensede konfiguration og jobidentifikatoren, ingen input fra besøgende og ingen loginoplysninger. Det er i øjeblikket ikke sat op (slået fra som standard). Uden proben er der ingen dokumentation fra en anden placering; en alarm bygger da på vores egen måling. |
| Kilde | Konfigureret af Kunden; resultater fra hentning af Kundens side. |
| Retsgrundlag (fastlagt af den dataansvarlige) | Fastlægges af Kunden for indholdet af Kundens website og for ansvarsområderne for Kundens medarbejdere. |
| Modtagere | Kunden; hvor en probe er sat op, dens operatør (i øjeblikket ingen). |
| Tredjeland | Intet. |
| Opbevaring | Resultater af browserkørsler, afsluttede browserjobs og tidsserier efter 13 måneder (natlig sletningskørsel, delene »browser_runs«, »browser_jobs«, »form_performance«). Konfigurationer indtil domænet slettes (enkeltvis kan de ændres eller slås fra, men ikke slettes); sammen med domænet forsvinder de, sammen med kørsler, observationer og tidsserier, via fremmednøgler. |
| Hvad målingen beviser | Tider og tilstande fra vores kontrolbrowser. De måler ikke, hvad rigtige besøgende oplever, og beviser hverken gennemførelsesrater eller tabte henvendelser. |
| TOM'er | Afsnit 8. Navnlig: indsendelse teknisk forhindret; kun adresser på samme domæne; maskerede billeder; isoleret kontrolcontainer. |
A.7 »Fix it for me« – indsat formularkode
| Felt | Angivelse |
| Formål | Kunden indsætter koden til sin formular; en sprogmodel på vores egen hardware bygger beskyttelsesmodulet ind. Tilbage kommer den ændrede fil, en patch, resultatet af en syntakskontrol og en angivelse af, om kontrolkaldet faktisk er bygget ind. Uden indsat kode leverer tjenesten et færdigt modul med feltnavnene fra den seneste scanning. |
| Kategorier af registrerede | Personer, hvis data tilfældigvis er i den indsatte kode (såsom en modtageradresse, navne i kommentarer, loginoplysninger til en mailserver). |
| Kategorier af personoplysninger | Den indsatte kode, højst 30.000 tegn. I databasen kun en post i aktivitetsloggen (handlingen »fix_ai« med workspace og tidspunkt), som tæller med i den daglige grænse på i øjeblikket ti kald pr. workspace. |
| Kilde | Indsat af Kunden. |
| Retsgrundlag | Opfyldelse af aftalen med Kunden (art. 6(1)(b) GDPR) for selve koden; for tredjepartsdata, der tilfældigvis er indeholdt i den, fastlægger Kunden grundlaget. |
| Modtagere | Ingen. Sprogmodellen kører på vores egen scanningsserver i det interne netværk; ingen ekstern AI-tjeneste, heller ikke som reserveløsning. |
| Tredjeland | Intet. |
| Opbevaring | Koden gemmes ikke. Der oprettes en midlertidig fil til syntakskontrollen, som slettes umiddelbart derefter. Posten i aktivitetsloggen slettes efter 365 dage. |
| Bemærkning til Kunden | Kode, der indeholder adgangskoder, API-nøgler eller personoplysninger, bør renses, før den indsættes. Vi kontrollerer ikke indholdet. |
| TOM'er | Afsnit 8. Navnlig: kun ejere og administratorer på betalte abonnementer; den indsatte kode gives til modellen markeret som data og udføres aldrig; ingen upload til tredjeparters servere. |
A.8 White label-brand og bureauets kontaktpersoner
| Felt | Angivelse |
| Formål | Et bureaus (Business-abonnement) rapporter, kortrapporter, dokumentationslogs og kundeportal vises under bureauets brand, efter ønske under et subdomæne af bureauets eget domæne. |
| Kategorier af registrerede | Kontaktpersoner hos bureauet, hvis navn eller kontaktoplysninger fremgår af kontaktlinjen. |
| Kategorier af personoplysninger | Virksomhedsnavn, website, kontaktlinje, bemærkning til kunden, accentfarve, udseende, logofil, kontakt for henvisningen til formexposed, eget domæne med verifikationsidentifikator og verifikationsstatus (workspace_branding). |
| Kilde | Indtastet af bureauet. |
| Retsgrundlag | Opfyldelse af aftalen med bureauet (art. 6(1)(b) GDPR). Hvor kontaktlinjen nævner bureauets medarbejdere, fastlægger bureauet grundlaget. |
| Modtagere | Enhver, som bureauet giver en rapport, en kortrapport eller et portallink. |
| Tredjeland | Intet. |
| Opbevaring | Indtil bureauet ændrer det; brand og logofil forsvinder sammen med workspacet (fe_arbeitsbereich_daten_loeschen()). Et eget domæne, hvis DNS-verifikation mislykkes i syv dage, slås fra. Eget domæne er slået fra som standard. |
| TOM'er | Afsnit 8. |
A.9 Tællinger, statusindikatorer og feltfejl fra plugin og udvidelse
| Felt | Angivelse |
| Formål | Én gang om dagen rapporterer WordPress-pluginnet og TYPO3-udvidelsen tal om formularerne på det tilsluttede website: blokerede indsendelser pr. årsag, indsendelser, sendte og mislykkede e-mails, statusindikatorer for formularindstillingerne, gemte henvendelser pr. kilde og opbevaringsperiode. Valgfrit, slået fra som standard: formularhændelser og feltfejlkategorier pr. feltposition. Disse tal giver »Beskyttelse i tal«, den månedlige rapport, stilhedsalarmen og bemærkninger om risikable indstillinger. |
| Klassificering | Tallene er udformet, så de ikke beskriver nogen person. Vi opfører dem i del A, fordi de opstår af hændelser på Kundens website, der udløses af Kundens besøgende; efter vores opfattelse er de højst i grænsetilfælde personoplysninger (et website med meget få indsendelser på en given dag). Selve overførslen (nøgler, versioner, host) står i del B (B.20). |
| Kategorier af registrerede | Besøgende på Kundens website, der indsender en formular. |
| Kategorier af personoplysninger | Daglige tal pr. host: blokeret i alt og pr. årsag, indsendelser, sendte og mislykkede e-mails, fejlkategori for e-mailafsendelse (kun én af fire kategorier, aldrig fejlteksten, fordi den kan indeholde modtageradresser), antal reCAPTCHA-svar, slettede og frigivne henvendelser (plugin_stats). Status: versioner fra en fast liste over formular-, CAPTCHA- og mailplugins, indstillingsindikatorer som tal, opbevaringsperioder (plugin_health). Ændringsmeddelelser: navn og version på et opdateret plugin (plugin_changes). Valgfrit: tællere pr. formular og dag med fejlkategorier pr. feltposition (form_metrics). Aldrig: input, feltnavne, adgangskoder, filer, e-mailadresser, navne, IP-adresser eller vedvarende identifikatorer for besøgende. |
| Kilde | Pluginnet på Kundens website via en programmeringsgrænseflade med websitets forbindelseshemmelighed. |
| Retsgrundlag (fastlagt af den dataansvarlige) | Fastlægges af Kunden; Kunden bestemmer, om de valgfrie tællinger skal aktiveres, og hvordan de besøgende oplyses. |
| Modtagere | Kunden. Domæner fra links i blokerede beskeder indgår i sværmbeskyttelsen (B.21). |
| Tredjeland | Intet. |
| Opbevaring | Daglige tal, ændringsmeddelelser og formulartællere efter 13 måneder (natlig sletningskørsel, delene »plugin_stats« og »form_metrics«). Statusindikatorer overskrives ved hver rapport. Alle plugindata for en host forsvinder, så snart intet domæne i systemet længere henviser til denne host (straks ved sletning af det sidste domæne; ældre data natligt, delen »orphan_hosts«). |
| Hvad tallene beviser | Hvad pluginnet har talt. De beviser hverken gennemførelsesrater eller tabte henvendelser. |
| TOM'er | Afsnit 8. Navnlig: modtagelse kun med websitets bundne nøglepar; kun kendte nøgler og tal accepteres, alt andet kasseres; dage uden for et vindue på 14 dage afvises. |
A.10 Grænse: hvad der kun forbliver på Kundens website
Følgende funktioner i WordPress-pluginnet og TYPO3-udvidelsen behandler data udelukkende på Kundens server. De når ikke os, og vi har ingen adgang til dem. Alene websiteoperatøren er ansvarlig; operatøren bestemmer over aktivering, opbevaringsperioder og hvordan de besøgende oplyses. Til dette formål foreslår pluginnet afsnit til operatørens privatlivspolitik.
| Funktion | Hvad der behandles lokalt | Opbevaring på Kundens side |
| Karantæne | Stoppede indsendelser med årsag, kan frigives pr. e-mail til websitets adresse | 14 dage |
| Sikkerhedsnet | Indsendelser, hvis formular-e-mail mislykkedes, til genafsendelse (slået til som standard) | 30 dage |
| Regneopgave i stedet for reCAPTCHA | Regneopgave i den besøgendes browser, ingen tredjepartstjeneste (slået fra som standard) | – |
| Indstillinger for opbevaring | Sletning af gemte henvendelser i formularplugins efter den periode, operatøren har valgt (slået fra som standard) | som konfigureret |
| Hastighedsbegrænsning | en kortlivet identifikator udledt af IP-adressen, overføres ikke til os | kortlivet |
| Lokale daglige tællere | Tællerværdier før overførsel | højst 14 dage |
| Optager for administratorer | tekniske selektorer og navigationstrin i sessionslageret i en indlogget administrators browser; input læses ikke. Kun den valgte konfiguration overføres (derefter A.6) | højst 15 minutter |
| Hjælp til besøgende | kan aktiveres separat; gemmer ingen kladder og sender ikke automatisk igen | – |
| Observation af nye spamregler | yderligere hits tælles lokalt, uden automatisk aktivering | syv dage |
A.11 Formularbeskyttelse (formconfirmed)
| Felt | Oplysning |
| Formål | Vurdering af indsendelser via formularer på Kundens websites for at genkende automatiserede indsendelser: udstedelse og kontrol af opgaver (beregningsbevis), engangskontroltokens, udfyldningstid, fældefelt, gentagne forespørgsler; efter Kundens ønske vurdering af beskedteksten ved hjælp af en sprogmodel. Kun for Kunder, der slår formularbeskyttelsen til. |
| Kategorier af registrerede | Besøgende på Kundens websites, der åbner en side med en beskyttet formular eller indsender den. |
| Kategorier af personoplysninger | IP-adresse (gemmes kun forkortet og hashet med en nøgle, der skifter dagligt), sidens adresse og domæne, tidspunkter og udfyldningstid, fældefelt udfyldt ja/nej, browseridentifikation i webserverloggen; kun når indholdskontrollen er slået til, beskedteksten (kun i arbejdshukommelsen). |
| Kilde | Den besøgendes browser (opgave, kontroltoken); Kundens server (kontrolanmodning, i givet fald tekst). |
| Modtagere | Kunden (score, handling, begrundelser). Ingen andre; ingen underdatabehandlere for denne behandling. |
| Tredjeland | Intet. |
| Opbevaring | Hashet identifikator 1 time; brugte kontroltokens højst 11 minutter; kontrolresultater uden IP-adresse og uden tekst 30 dage; daglige tal 400 dage; webserverlog 14 dage; tekst gemmes ikke. |
| TOM'er | Afsnit 8; derudover forkortelse og hashing med daglig nøgle, signerede opgaver, engangsbrug, sprogmodel på egen hardware uden logning af teksten. |
4. Del A – modtagere, underdatabehandlere og overførsler til tredjelande
Følgende tabel opfører de modtagere, som vi selv gør brug af, og som kan modtage data fra del A. Den autoritative, løbende opdaterede liste er siden Underdatabehandlere; hvis den afviger fra denne tabel, er det et fund, ikke et formateringsspørgsmål.
| Modtager | Hvad den modtager | Tredjeland | Grundlag | Status |
| Namecheap, Inc. (Private Email), Phoenix, Arizona, USA | Kontrolpostkasse til leveringskontrollen (A.1); afsendelse af alarm-e-mails (A.3), bekræftelser og rapporter til portalabonnenter (A.2) | Behandlingssted skal stadig verificeres; se siden »Underdatabehandlere« | Databehandleraftale; overførselsgrundlag skal stadig verificeres | Åbent. Den relevante aftale, de faktiske behandlingssteder og overførselsgrundlaget er endnu ikke dokumenteret. Denne fortegnelse bekræfter hverken en certificering eller en indgået aftale. |
| Namecheap, Inc. (registrator, DNS; videresendelse af e-mail, indtil postkassen er sat op) | Indtil postkassen er sat op, generel indgående post til adresser på vores domæne; ikke kopierne fra leveringskontrollen, som kun ankommer med MX-poster, der peger direkte på postkassen (A.1) | USA | skal verificeres: certificering under databeskyttelsesrammen mellem EU og USA eller standardkontraktbestemmelser | I brug; grundlag åbent. |
| Vores egen scanningsserver med en lokal sprogmodel | Formularstruktur til klassificering (A.4), indsat kode (A.7), dekrypteret testadgang kun under kørslen (A.5) | – | Drevet af os, ikke en tredjepart | I brug. |
| Uafhængig probe på en anden placering | Domæne, renset konfiguration, jobidentifikator (A.6) | afhængigt af placering | fastlægges inden ibrugtagning | Ikke sat op. |
Hosting: ingen tredjepart. Applikation, database, skærmbilleder og sikkerhedskopier opbevares på vores egne servere i Polen. Hvis vi flytter til et datacenter eller en cloududbyder, skal dette afsnit omskrives.
4.1 Alarmkanaler valgt af Kunden
Ud over de modtagere, vi gør brug af, er der kanaler, som Kunden vælger til sine alarmer (A.3). Vores server udløser overførslen; Kunden bestemmer modtageren og udbyderen. Valget af en kanal fritager os ikke for vores egne forpligtelser som databehandler. Rolle, aftale og de garantier, der kræves for tredjelande, skal fastlægges for hver udbyder; for chattjenesterne er dette endnu ikke afsluttet (åbent spørgsmål til den juridiske gennemgang).
| Kanal | Hvad der sendes | Udbyderens hjemsted |
| E-mail | Domæne, hændelse, forklaring, link; til den indtastede adresse | via Namecheap, Inc. (Private Email), Phoenix, Arizona, USA |
| Webhook til en frit valgt adresse | Hændelse som JSON (domæne, hændelser, linjer, link, tidsstempel), signeret med modtagerens hemmelighed | fastlægges af Kunden |
| Slack, Discord, Microsoft Teams, Google Chat | den samme notifikation som chatbesked til den indtastede webhook-adresse | overvejende USA |
| Telegram | modtager valgt af Kunden; vi sender beskeden via vores bot til det forbundne chat-ID | uden for EU, ingen afgørelse om tilstrækkeligheden af beskyttelsesniveauet; overførselsgrundlaget er et åbent spørgsmål til den juridiske gennemgang |
Indholdet af en besøgendes besked sendes under ingen omstændigheder. Notifikationerne indeholder domæne, hændelse og link.
5. Del B – art. 30(1): behandling under vores eget ansvar
Dataansvarlig for alt i denne del: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, contact@lukaswojcik.com. Ingen repræsentant påkrævet (etableret i Unionen). Ingen databeskyttelsesrådgiver udpeget (afsnit 9). Tekniske og organisatoriske foranstaltninger: afsnit 8 og siden Tekniske og organisatoriske foranstaltninger. Hvordan registrerede udøver deres rettigheder, er beskrevet på siden Indsigt, sletning og dine øvrige rettigheder; kontoindehavere kan selv downloade deres data som fil (Indstillinger).
Hvor vi støtter os på legitime interesser (art. 6(1)(f) GDPR), nævner vi interessen og grunden til, at et mindre indgribende middel ikke er tilstrækkeligt. Afvejningen er vores vurdering; den er en del af den juridiske gennemgang.
B.1 Besøgende på vores website – webserverlogs
| Felt | Angivelse |
| Formål | Drift og sikkerhed af websitet og appen: levering, fejlfinding, opdagelse af angreb og overbelastning. |
| Kategorier af registrerede | Alle, der åbner en side på formexposed.com eller form.exposed, herunder besøgende på kundesider, hvis browser indlæser vores badgebillede (B.18), modtagere, der åbner et rapport- eller kvitteringslink, og websites, hvis plugin kalder vores grænseflade. |
| Kategorier af personoplysninger | Fuld IP-adresse, tidspunkt, forespurgt adresse, statuskode, overførte bytes, henvisende side (referrer), browseridentifikator (user agent). |
| Lagringssted | Adgangslogs fra den forankoblede proxy og fra webserveren som filer på webserveren, ikke i databasen. |
| Kilde | Den browser eller det program, der foretager forespørgslen. |
| Retsgrundlag | Art. 6(1)(f) GDPR. Interesse: sikker og uafbrudt drift. Afvejning: Uden den fulde adresse kan gentagne forespørgsler fra samme afsender ikke kædes sammen, og angreb kan ikke afværges; en afkortet adresse understøtter ikke denne sondring. Logfilerne kombineres ikke med andre data og slettes efter kort tid. |
| Modtagere | Ingen. |
| Tredjeland | Intet. |
| Opbevaring | 14 dage: daglig rotation med 14 generationer, derefter overskrevet (systemets logrotationstjeneste, ikke applikationens natlige sletningskørsel). |
| TOM'er | Afsnit 8. |
B.2 Applikationens sidevisningslog
| Felt | Angivelse |
| Formål | Sikkerhed og opdagelse af misbrug (hvem der forespørger hvad og hvor ofte), sporbarhed af kontoadgang, enkel brugsstatistik uden analysetjeneste. |
| Kategorier af registrerede | Alle besøgende på websitet og brugere af appen ved ægte sidevisninger (ingen baggrundsforespørgsler, ingen formularindsendelser). |
| Kategorier af personoplysninger | Fuld IP-adresse, det land, der udledes af den ved skrivningen (lokal geodatabase, ingen forespørgsel til en tredjepart), konto-ID for indloggede brugere, forespurgt adresse og henvisende side (adgangstokens heri, såsom tokens i rapport- eller portallinks, maskeret), browseridentifikator og den enhedstype, det styresystem og den browser, der udledes heraf, sprog, tidspunkt (access_logs). Under »Se som kunde« (B.14) sættes intet konto-ID, så supportens sidevisninger ikke vises i Kundens log. |
| Kilde | Browserens forespørgsel. |
| Retsgrundlag | Art. 6(1)(f) GDPR. Interesse: forebyggelse af misbrug og sporbarhed. Afvejning: som B.1; opbevaringsperioden er længere, fordi misbrugsmønstre bliver synlige over uger. Om IP-adressen bør afkortes eller opbevaringsperioden forkortes, er et åbent spørgsmål til den juridiske gennemgang. |
| Modtagere | Ingen. Kontoindehavere modtager deres egne sidevisninger i dataeksporten. |
| Tredjeland | Intet. |
| Opbevaring | 60 dage (natligt mellem kl. 03:00 og 03:05, srv/cron_status.php, indstillingen »sidevisningslog«). |
| TOM'er | Afsnit 8. IP-adressen hentes kun fra en videresendt header, hvis forespørgslen kommer fra vores egen forankoblede proxy, og da kun den post, som denne proxy har tilføjet; ellers kunne enhver angive sin oprindelse efter forgodtbefindende. |
B.3 Cookies og lagring i browseren
| Felt | Angivelse |
| Formål | Teknisk nødvendig lagring: session, beskyttelse mod cross-site request forgery (CSRF), optælling af grænserne for kontroller uden konto, login, forbliv logget ind efter ønske, lys eller mørk visning. |
| Kategorier af registrerede | Besøgende og brugere af formexposed.com. |
| Kategorier af personoplysninger | Sessionscookie bpid (sessionsidentifikator; ophører, når browseren lukkes; HttpOnly, SameSite=Lax, Secure via HTTPS). Cookie bp_remember kun efter valg af »Forbliv logget ind« (selektor og verifikator; 30 dage). Lokalt lager bp_theme (lys, mørk eller system). I administrationsområdet desuden operatørernes lokale visningsindstillinger. Til grænserne dannes en hash af sessionsidentifikatoren; selve identifikatoren gemmes ikke. |
| Sættes ikke | Ingen analyse-, reklame- eller sporingscookies. Partnerprogrammet (B.33) fungerer uden cookie. Badgebilledet på kundesider sætter ingen cookie (B.18). reCAPTCHA kan sætte cookies fra Google, når en beskyttet formular indsendes (B.23). |
| Retsgrundlag | Adgang til terminaludstyret: strengt nødvendig for den tjeneste, brugeren har anmodet om (§ 25(2) nr. 2 TDDDG, den tyske lov om databeskyttelse inden for telekommunikation og digitale tjenester; art. 399(3) PKE, den polske lov om elektronisk kommunikation (Prawo komunikacji elektronicznej)). Behandling: art. 6(1)(b) GDPR (konto) og (f) (sikkerhed, grænser). |
| Modtagere | Ingen. |
| Tredjeland | Intet. |
| Opbevaring | Session; 30 dage for remember-tokenet. Den natlige kørsel sletter udløbne remember-tokens i databasen (remember_tokens); ved logout, ændring af adgangskode og tilbagekaldelse af en enhed straks. |
| TOM'er | Afsnit 8. |
B.4 Gratis kontrol uden konto – modtagelse, grænser og overvågning af misbrug
| Felt | Angivelse |
| Formål | Enhver kan få et domæne kontrolleret uden konto. For at inputfeltet ikke skal blive et våben mod tredjeparters websites, gælder trinvise grænser: én anonym kontrol pr. domæne på syv dage (derefter samme rapport), grænser pr. IP-adresse og pr. session på 24 timer, en daglig grænse for hele systemet, blokering af meget unge domæner, blokeringsliste og opt-out, kun offentlige adresser. Iøjnefaldende mønstre registreres og rapporteres til operatøren. Grænserne pr. IP-adresse, pr. session og for hele systemet, hver for sig talt separat, gælder også for kontrollen fra pluginnet uden konto (et plugin med et bundet nøglepar tælles pr. website i stedet for pr. adresse) og for opt-out (B.30); det gratis header-værktøj (B.9) har sine egne grænser pr. IP-adresse og dag og for hele systemet. |
| Kategorier af registrerede | Personer, der udløser en kontrol, en forespørgsel i header-værktøjet eller en opt-out; servere, hvorpå et plugin er installeret. |
| Kategorier af personoplysninger | Log over hver forespørgsel: kilde (kontrol, plugin, header-værktøj, opt-out), fuld IP-adresse, hash af sessionsidentifikatoren, kontrolleret host, land ud fra IP-adressen, accepteret eller afvist med årsag, tidspunkt (check_throttle). Uregelmæssigheder: type (IP-adresse, session, land, system), nøgle (for typen »IP« den fulde IP-adresse), mønster, alvorlighed, kort beskrivelse, tidspunkter for registrering og afklaring, afklarende person (abuse_flags). Job: host, tilstand, tillidsniveau og en afkortet sessionshash som identifikator for anmoderen (scan_jobs). Rapport: tilfældig identifikator, host, sprog, udløb, første visning, antal visninger (reports). Cachelagret domænealder fra registeropslaget (domain_age_cache). |
| Kilde | Personens input; personens forespørgsel; registeropslag (RDAP) for domænealderen. |
| Retsgrundlag | Udførelse af den anmodede kontrol: art. 6(1)(b) GDPR (brug af den gratis kontrol i henhold til servicevilkårene); subsidiært (f). Grænser og overvågning: art. 6(1)(f). Interesse: at forhindre, at tjenesten bruges som værktøj mod tredjeparters websites eller som spamkanon. Afvejning: Uden kobling til adressen og sessionen kunne grænserne ikke håndhæves; perioden på syv dage er lige så kort som den længste grænse, der tælles ud fra den. |
| Modtagere | Google (reCAPTCHA ved indsendelse, B.23). For domænealderen forespørger scanneren RDAP-omdirigeringstjenesten rdap.org, som videresender til det ansvarlige register; kun domænenavnet overføres. Ved en uregelmæssighed modtager operatøren et signal via Telegram uden nogen variabel (ingen host, ingen adresse). Rapporten kan ses af den, der har dens tilfældige link. |
| Tredjeland | USA via reCAPTCHA (B.23). |
| Opbevaring | Forespørgselslog 7 dage (natligt, srv/cron_status.php). Afklarede uregelmæssigheder 90 dage efter afklaring; uafklarede forbliver, indtil nogen afklarer dem (afsnit 10). Anonyme rapporter udløber efter 30 dage; den natlige kørsel sletter derefter rapport, job, kontrolresultat, formularer, fund og billeder (fe_reports_aufraeumen()). En administrator kan manuelt frigive poster for en adresse; dette sletter dens log for de seneste 24 timer. |
| TOM'er | Afsnit 8. Nødstop for alle anonyme kontroller i administrationsområdet; modtryk, der ikke accepterer nye gratis kontroller, når der er en kø. |
B.5 Crawlerkontrol af tredjeparters websites
| Felt | Angivelse |
| Formål | Sikkerhedskontrol af offentlige kontaktformularer: beskyttelse mod spam og misbrug, kendetegn for databeskyttelse og tilgængelighed, indlejrede tredjepartsscripts, adfærd efter afvisning i cookiebanneret, mobilvisning. Gælder for kontroller uden konto (B.4), for domæner på en konto, der endnu ikke er verificeret, og som grundlag for undersøgelsen (B.7) og kontrollen af potentielle kunder (B.8). For verificerede domæner på en konto handler vi på Kundens vegne (A.4). |
| Crawlerens adfærd | Egen identifikator med henvisning til crawlersiden; læser robots.txt før kontrollen og stopper, hvis en disallow-regel omfatter forsiden (ligeledes hvis robots.txt ikke kan nås, eller der er en serverfejl); disallow-regler for enkelte understier overholdes ikke separat. Formularpuls, hentning af dokumentation, header-værktøj og søgningen efter eksponerede filer læser ikke robots.txt. Højst otte offentlige sider pr. kontrol plus op til tre sider med et klik på »Afvis« i cookiebanneret, op til tre sider i mobilvisning, aktive prober for verificerede domæner og op til fem sider bag et login (A.5); siderne indlæses én efter én, ikke parallelt; kun offentlige adresser, ingen interne netværk, omdirigeringer kontrolleres igen; blokeringsliste og opt-out kontrolleres før modtagelsen og en gang til i scanneren. Passiv: Uden dokumentation for kontrol indsendes intet for Kunder (undtagelse: interne kontroller af vores egne test- og demodomæner, B.6). |
| Kategorier af registrerede | Operatører af de kontrollerede websites (hvor de er fysiske personer, f.eks. enkeltmandsvirksomheder); personer, der tilfældigvis er synlige på de kontrollerede sider. |
| Kategorier af personoplysninger | Som A.4: sideadresser og -titler, formularstruktur (feltnavne, -typer og -etiketter, ingen feltværdier), beskyttelsesforanstaltninger, tredjepartsscripts (adresser; konto-ID'er for pixels og optageværktøjer erstattes før lagring), cookiebannerets adfærd, skærmbilleder (synligt område af forsiden, formularer). Hvis en modtageradresse fremgår af formularen, kun dens domæne (scans, forms, findings, scan_screenshots). |
| Kilde | Offentligt tilgængelige sider. |
| Retsgrundlag | Art. 6(1)(f) GDPR. Interesse: udførelse af den anmodede sikkerhedskontrol; at gøre websiteoperatører opmærksomme på svagheder, der kan skade deres besøgende. Afvejning: Kun det, enhver besøgende ser, læses, i begrænset omfang og uden at indsende noget; operatøren kan til enhver tid permanent udelukke sit domæne uden dokumentation. Oplysning efter art. 14 GDPR gives via crawlersiden, opt-out og privatlivspolitikken; om dette er tilstrækkeligt efter art. 14(5)(b), er et åbent spørgsmål til den juridiske gennemgang. |
| Modtagere | Den, der udløser rapporten, og enhver, som vedkommende giver det tilfældige link; den lokale sprogmodel på vores egen server, hvor formulartypen er uklar (formularstruktur, sidetitel og -adresse, formularens synlige tekst). Sårbarhedsadvarsler ud fra plugin-versioner vises aldrig i anonyme rapporter. |
| Tredjeland | Intet. |
| Opbevaring | Anonymt: 30 dage (B.4). Kontrol af potentielle kunder: 90 dage (B.8). Undersøgelse: indtil offentliggørelse (B.7). Domæne på en konto: højst 13 måneder, den seneste kontrol bevares; straks sammen med domænet. Operatørens interne kontroller uden domæne og uden rapport (såsom dem, der oprettes fra kommandolinjen): ingen opbevaringsperiode (afsnit 10). Midlertidige filer på scanningsserveren slettes efter hver kørsel. |
| TOM'er | Afsnit 8. Navnlig: separat kontrolcontainer med reducerede rettigheder, skrivebeskyttet filsystem, hukommelsesgrænse og eget netværk; dobbelt målkontrol. |
B.6 Aktive testindsendelser
| Felt | Angivelse |
| Formål | Kontrol af, om en kontaktformular accepterer en indsendelse uden beskyttelse, om CAPTCHA, fælde (honeypot), token, validering af e-mailadresse og hastighedsbegrænsning virker på serversiden, og om headers kan indsprøjtes. |
| Forudsætning | For Kunder kun for domæner, for hvilke der er dokumenteret kontrol (DNS-post, metatag, fil eller tilsluttet plugin); derudover opretter operatøren via et internt kommandolinjeværktøj kontroller med niveauet »verificeret« for vores egne test- og demodomæner. Kun med den globale kontakt slået til, kun for en formular, der pålideligt er klassificeret som generel kontaktformular. Aldrig for bestillinger, bookinger, registreringer, nyhedsbreve, betalinger, filupload, obligatoriske felter med reelle personoplysninger eller domæner tilhørende offentlige myndigheder, sundheds- eller uddannelsesinstitutioner. |
| Kategorier af registrerede | Kundens medarbejdere, der modtager formular-e-mailene. |
| Kategorier af personoplysninger | Testindsendelsen indeholder ingen personoplysninger: afsender »FormExposed Security Scanner«, vores egen afsenderadresse eller en adresse under .invalid, en mærket emnelinje og en tekst på sidens sprog med henvisning til crawlersiden og opt-out samt kontrolnummeret. Gemt af os: sidens svar, fund, et billede af den efterfølgende side (som A.4). |
| Omfang | Højst fem indsendelser pr. kontrol (indstilling, standard 5); tilbagevendende med abonnementets kontrolhyppighed, dagligt i det højeste abonnement. |
| Kilde | Kundens instruks. |
| Retsgrundlag | Opfyldelse af aftalen med Kunden (art. 6(1)(b) GDPR); indsendelserne går til Kundens egen formular. For modtagerne hos Kunden: Kundens organisation. |
| Modtagere | Kunden (Kundens formular-e-mail). |
| Tredjeland | Intet via os. |
| Opbevaring | Resultater som A.4. |
| TOM'er | Afsnit 8. Header-injektion registreres kun og udføres aldrig med en rigtig modtager; valideringen af e-mailadressen bruger kun et domæne, der ikke kan eksistere. |
B.7 Undersøgelsen »Indeks for formularsikkerhed«
| Felt | Angivelse |
| Formål | Statistik over beskyttelsen af kontaktformularer i et land eller en branche. Kun samlede tal offentliggøres, uden navne på websites; segmenter først fra 20 sider med en formular. |
| Kategorier af registrerede | Operatører af websites på listen; tilfældigt synlige personer. |
| Kategorier af personoplysninger | Som B.5, kun passivt. Desuden listen: host, segment, status, job (study_domains); undersøgelse med titel, land, samlede resultater (studies). |
| Kilde | En liste over offentlige websites sammensat af operatøren; selve siderne. |
| Retsgrundlag | Art. 6(1)(f) GDPR. Interesse: statistiske udsagn om tilstanden af formularsikkerhed. Afvejning: passiv, begrænset hastighed (få jobs pr. kørsel), blokeringsliste og opt-out gælder, offentliggørelse kun som samlede tal, rådata slettes. |
| Modtagere | Offentligheden, kun samlede tal. |
| Tredjeland | Intet. |
| Opbevaring | Rådata (kontrolresultater, formularer, fund, billeder, jobs) slettes ved offentliggørelsen (fe_studie_veroeffentlichen()). Listen over hosts med segment forbliver derefter; der er ingen opbevaringsperiode for den eller for undersøgelser, der aldrig offentliggøres (afsnit 10). Operatøren bestemmer, hvilke lister der kontrolleres, og om undersøgelser offentliggøres. |
| TOM'er | Afsnit 8. |
B.8 Kontrol af potentielle kunder (kundeerhvervelsestilstand for bureauer)
| Felt | Angivelse |
| Formål | Et bureau (Business-abonnement) kontrollerer passivt en potentiel kundes website og modtager en kortrapport under sit brand og den passive rapport. Vi kontakter ingen; bureauet videregiver selv linket. |
| Kategorier af registrerede | Operatør af det kontrollerede website; tilfældigt synlige personer; bureauets medarbejdere, der udløser kontrollen. |
| Kategorier af personoplysninger | Som B.5, kun passivt. Desuden: workspace, den person, der udløser kontrollen, host, rapportens tilfældige identifikator, tidspunkt (prospect_checks). |
| Kilde | Bureauets input; offentlige sider. |
| Retsgrundlag | Art. 6(1)(f) GDPR (vores interesse i at levere tjenesten og bureauets interesse i en velfunderet henvendelse). Bureauets og vores roller og bureauets forpligtelser ved videregivelse af rapporten er åbne spørgsmål til den juridiske gennemgang: Hvis bureauet sender rapporten uopfordret pr. e-mail eller ringer, er det direkte markedsføring, der kræver samtykke efter art. 398 PKE og § 7(2) UWG (den tyske lov mod illoyal konkurrence), også mellem virksomheder. Det er bureauets ansvar; servicevilkårene forpligter det i overensstemmelse hermed. |
| Modtagere | Bureauet og enhver, som det giver linket. |
| Tredjeland | Intet. |
| Opbevaring | Rapport og kontrolresultat udløber efter 90 dage og slettes derefter af den natlige kørsel (fe_reports_aufraeumen()); kontrolposten slettes efter 90 dage i den daglige sværmkørsel fra kl. 04:00 (srv/cron_status.php). Sammen med workspacet straks. |
| TOM'er | Afsnit 8. Månedlig kvote (indstilling, standard 30); samme side inden for syv dage giver samme rapport; opt-out gælder. |
B.9 Header-værktøj uden konto
| Felt | Angivelse |
| Formål | Gratis karakter (A+ til F) for sikkerhedsheaderne på et domænes forside. To forespørgsler, ingen browser, ingen formular, ingen indsendelse. |
| Kategorier af registrerede | Personer, der bruger værktøjet; operatører af det kontrollerede domæne. |
| Kategorier af personoplysninger | Forespørgselslog som B.4 (kilde »headers«, IP-adresse, sessionshash, host). Resultat: host, karakter, point, evaluerede headers (header_checks). |
| Retsgrundlag | Art. 6(1)(f) GDPR, som B.4 og B.5. |
| Modtagere | Google (reCAPTCHA, B.23). |
| Tredjeland | USA via reCAPTCHA. |
| Opbevaring | Forespørgselslog 7 dage; resultater efter i øjeblikket 90 dage (natlig sletningskørsel, delen »header_checks«, indstillingen »headers_keep_days«). For domæner på en konto fastsættes karakteren igen dagligt og gemmes ved domænet. |
| TOM'er | Afsnit 8. Grænser pr. IP-adresse og dag; opt-out gælder. |
B.10 Kundekonti
| Felt | Angivelse |
| Formål | Drift af kundekonti, workspaces og abonnementer. |
| Kategorier af registrerede | Kunder (virksomheder) og deres teammedlemmer med egen konto. |
| Kategorier af personoplysninger | E-mailadresse og normaliseret form, adgangskode kun som hash, fornavn (obligatorisk), efternavn og virksomhed (hvis angivet); applikationen gemmer ikke adresse og momsnummer, de angives kun hos Stripe (B.26); status, sprog, visningstilstand, valuta, abonnement og faktureringsstatus, Stripe-kunde- og abonnements-ID, afslutning af faktureringsperioden, opsigelse ved periodens udløb, bekræftelses- og nulstillingsidentifikatorer med udløb, ny e-mailadresse indtil bekræftelse, tidspunkt for registrering, seneste login og seneste IP-adresse, tidspunkt for tilbagekaldelse af alle sessioner, tofaktordata (B.11), månedlig rapport til/fra, tidspunkt for påmindelses-e-mail, oplåsninger via koder, henvisningskode og henvisning (users). Workspaces med navn, tidspunkter, status (workspaces); medlemskab med rolle og tiltrædelsesdato (workspace_users). |
| Kilde | Personens registrering og indstillinger; faktureringsstatus fra Stripe. |
| Retsgrundlag | Art. 6(1)(b) GDPR (aftale). Seneste IP-adresse: (f) (kontosikkerhed). |
| Modtagere | Stripe (B.26); mailtjenesteudbyder til konto-e-mails (B.25). Medlemmer af samme workspace ser de øvrige medlemmers navn, e-mailadresse og rolle. |
| Tredjeland | Via Stripe og mailtjenesteudbyderen. |
| Opbevaring | Indtil sletning af kontoindehaveren. Ved sletning forsvinder indehaverens egne workspaces, som ingen andre bruger, med alle domæner og 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. Medlemskaber, remember-tokens, enheder, API-nøgler, åbne Telegram-koder, feedback på rapporter (B.35) og kontorækken slettes; et løbende betalt abonnement afsluttes først straks hos Stripe uden refusion (www/ajax.php, fe_konto_reste_loeschen()). En opsigelse i faktureringsområdet får derimod virkning ved periodens udløb; derefter fortsætter kontoen på det gratis abonnement. Hvad der forbliver, fremgår af afsnit 6.4. Konti, der aldrig er bekræftet og aldrig har været logget ind, slettes efter 30 dage, medmindre et andet medlem er knyttet til deres workspace (natlig sletningskørsel, delen »pending_accounts«). Der sker ingen sletning af inaktive konti. Hvis aftalen om kontoen ophører på anden måde, f.eks. ved vores opsigelse, sletter vi kontoen senest 30 dage efter aftalens ophør; dette sker i øjeblikket manuelt (forpligtet i databehandleraftalen). |
| TOM'er | Afsnit 8. |
B.11 Login, enheder, anden faktor og aktivitetslog
| Felt | Angivelse |
| Formål | Beskyttelse af konti: begrænsning af login- og andre adgangskodeforsøg, visning og tilbagekaldelse af indloggede enheder, tofaktorlogin, sporbarhed af ændringer. |
| Kategorier af registrerede | Kontoindehavere og teammedlemmer; personer, der forsøger et login, en registrering eller adgangskoden til en kundeportal. |
| Kategorier af personoplysninger | Loginforsøg: IP-adresse, indtastet e-mailadresse, succes, tidspunkt (login_attempts). Enheder: hash af sessionsidentifikatoren (aldrig selve identifikatoren), link til remember-tokenet, IP-adresse, browseridentifikator og den browser, det styresystem og den enhedstype, der udledes heraf, tidspunkter for login, seneste aktivitet og tilbagekaldelse samt ved »Se som kunde« supportpersonens identifikator (login_sessions). Remember-tokens til »Forbliv logget ind«: selektor, verifikator, udløb (remember_tokens). Tofaktor: hemmelighed krypteret, tidspunkt for aktivering, senest anvendte tidstrin, gendannelseskoder kun som hash (i users). Aktivitetslog: konto, workspace, handling, mål, detaljer, IP-adresse, land, tidspunkt (audit_logs). Forsøgstællere for login, anden faktor, bekræftelse af adgangskode, nulstilling af adgangskode, registrering og adgangskoder til kundeportaler: en HMAC-nøgle udledt af formålet og konto-ID'et (for en ukendt adresse eller ved nulstilling den e-mailadresse, der er konverteret til små bogstaver), IP-adressen, konto og IP-adresse tilsammen eller portal-ID'et (også sammen med IP-adressen), antal forsøg, udløb; e-mail- og IP-adresser gemmes ikke der i klartekst (tabellen auth_attempt_buckets). |
| Retsgrundlag | Art. 6(1)(b) GDPR sammenholdt med art. 32 (enhedsliste, anden faktor) og (f) (loginforsøg, aktivitetslog). Interesse: beskyttelse af konti mod overtagelse, dokumentation af ændringer (art. 5(2)). Afvejning: En afkortet adresse besvarer ikke spørgsmålet »var det mig?«; aktivitetsloggen skal overleve en tvist, der først opstår måneder senere. |
| Modtagere | Ingen. Kontoindehaveren ser sine enheder og modtager loginforsøg, enheder og aktiviteter i dataeksporten; under en »Se som kunde«-session vises hverken supportpersonens IP-adresse eller browser der. |
| Tredjeland | Intet. |
| Opbevaring | Loginforsøg 7 dage; efter et vellykket login slettes de mislykkede forsøg fra samme adresse straks. Forsøgstællere ved udløbet af deres tidsvindue (i øjeblikket 15 minutter, en time ved nulstilling af adgangskode og registrering); udløbne slettes ved næste adgang og af den natlige kørsel. Enheder 90 dage efter seneste brug eller efter tilbagekaldelse (natlig sletningskørsel, delen »sessions«), straks sammen med kontoen. Remember-tokens udløber efter 30 dage. Aktivitetslog 365 dage (natligt); når en konto slettes, forbliver dens poster indtil udløbet af opbevaringsperioden (afsnit 6.4). |
| TOM'er | Afsnit 8. |
B.12 Dokumentation for aftaleindgåelse
| Felt | Angivelse |
| Formål | Dokumentation af, hvilken version af servicevilkårene, databehandleraftalen og privatlivspolitikken en Kunde har accepteret eller taget til efterretning ved registreringen, og at Kunden bruger tjenesten til sin virksomhed. |
| Kategorier af registrerede | Kunder. |
| Kategorier af personoplysninger | Pr. dokument: konto, dokument, version (hash af den viste tekst), anledning, IP-adresse, browseridentifikator, tidspunkt (legal_consents). Selve den viste version med fuld tekst, sprog, titel og adresse, én gang pr. version (legal_versions; indeholder ingen personoplysninger). |
| Retsgrundlag | Art. 6(1)(b) og (f) GDPR (dokumentation for aftaleindgåelse, forsvar mod krav). |
| Modtagere | Ingen. Kontoindehaveren modtager sine registreringer i dataeksporten. |
| Tredjeland | Intet. |
| Opbevaring | Så længe kontoen eksisterer; efter sletning af kontoen fire år fra samtykket, derefter slettet natligt (srv/cron_status.php). Begrundelse i koden: treårig forældelsesfrist fra årets udgang, rundet op. Om polsk ret taler for en anden periode, er en del af den juridiske gennemgang. |
| TOM'er | Afsnit 8. Hvis et af de tre dokumenter mangler, er registreringen lukket. |
B.13 Teaminvitationer
| Felt | Angivelse |
| Formål | Invitation af yderligere personer til et workspace. |
| Kategorier af registrerede | Inviterede. |
| Kategorier af personoplysninger | E-mailadresse, rolle, invitationsidentifikator, inviterende person, udløb, tidspunkt for accept (workspace_invites); invitations-e-mailen i udbakken (B.25). |
| Kilde | Indtastet af det inviterende medlem. |
| Retsgrundlag | Art. 6(1)(b) GDPR i forhold til Kunden; over for den inviterede person (f) (Kundens interesse i at inddrage sit team). |
| Modtagere | Mailtjenesteudbyder (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tredjeland | Via mailtjenesteudbyderen. |
| Opbevaring | En invitation er gyldig i 14 dage og kun, så længe den inviterende person er ejer eller administrator af workspacet. Ikke-accepterede invitationer efter udløb, accepterede 30 dage efter accept (natligt, srv/cron_status.php og delen »invites« i cfg/fristen_lib.php). Sammen med workspacet straks. |
| TOM'er | Afsnit 8. |
B.14 »Vis som Kunde« via support
| Felt | Oplysning |
| Formål | En superadministrator ser applikationen, som en Kunde ser den, for at løse et supportspørgsmål (»knappen mangler hos mig«). |
| Kategorier af registrerede | Den pågældende Kunde; superadministratoren. |
| Kategorier af personoplysninger | Alt, hvad Kunden ser i applikationen. Logges: en separat enhedsrække med superadministratorens identifikator (login_sessions), start og slut i aktivitetsloggen (audit_logs). |
| Retsgrundlag | Art. 6(1)(b) GDPR (support som en del af tjenesten), alternativt (f). |
| Begrænsninger | Højst én time, derefter fuldstændig udlogning. Når visningen afsluttes, logges superadministratoren også helt ud, herunder af den session, vedkommende kom fra; adgangen til administrationsområdet genvindes kun ved at logge ind igen med adgangskode og anden faktor. Afsluttes straks, hvis superadministratoren nedgraderes eller blokeres. Alt, der ændrer Kundens konto, er spærret: adgangskode, e-mailadresse, anden faktor, enheder, abonnement, eksport, sletning, overdragelse. Administrationsområdet er lukket under sessionen. Kunden ser adgangen i sin enhedsliste og i dataeksporten som supportadgang. |
| Modtagere | Ingen. |
| Tredjeland | Ingen. |
| Opbevaring | Enhedsrække 90 dage, aktivitetslog 365 dage. |
| TOM'er | Afsnit 8. |
B.15 Domæner, bevis for kontrol og overvågning
| Felt | Oplysning |
| Formål | Kernetjenesten for Kunder: at have domæner i kontoen, føre bevis for kontrol, kontrollere regelmæssigt og opdage ændringer. Hertil hører formularpulsen (en let forespørgsel uden browser hvert 10. til 30. minut afhængigt af planen), den daglige overvågning af mail-DNS og certifikater, domænets udløbsdato, blokeringslister, eksponerede filer, versioner, der er synlige udefra, scriptoversigt, visuelle ændringer af formularen, nedbrud hos CAPTCHA- og mailudbydere samt sårbarhedsovervågningen af formular-plugins. |
| Kategorier af registrerede | Kunder og deres teammedlemmer; dem, der driver domænerne, for så vidt de er fysiske personer. |
| Kategorier af personoplysninger | Domæne med host, offentlig identifikator, note, kundemærkat, bevistype og -identifikator, kontrolhyppighed, overvågning til/fra, vedligeholdelsesvinduer, henvendelsesværdi, identifikatorer for badge, leveringskontrol og deploy-hook, plugin-nøgle, tilstande og seneste resultater af overvågningerne (DNS, certifikat, ægtheden af formularens e-mail, blokeringslister, eksponerede filer, headere, versioner) (domains). Puls pr. formularside (form_pulse). Sårbarheder ud fra plugin-versioner (vuln_hits). Scriptoversigt med adresse, hash, størrelse, godkendelse med godkendende person og begrundelse (script_inventory, script_changes). Kontroller som A.4. For eksponerede filer gemmes sti, alvorlighed og type, aldrig indholdet. |
| Forespørgsler til tredjeparter | DNS-forespørgsler (SPF, DMARC, MX, bevispost). Registeropslag via RDAP i henhold til IANA-kataloget: kun domænenavnet. DNS-blokeringslister (SpamCop, PSBL, Mailspike, SURBL; Spamhaus kun med gemte adgangsoplysninger, i øjeblikket ikke): IP-adresser på web- og mailserveren samt domænenavnet, ingen besøgsdata. Google Web Risk kun, hvis det er sat op (i øjeblikket ikke): adressen på forsiden. Tidsstemplingsmyndighed: kun en hashværdi (B.19). WPVulnerability: kun identifikatoren for et plugin eller tema eller WordPress-versionen; sammenligningen med den installerede plugin-version foretager vi selv. Statussider for Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun og Brevo: der overføres intet ud over selve forespørgslen. |
| Kilde | Kunden; forespørgsler til Kundens side; offentlige kataloger. |
| Retsgrundlag | Art. 6(1)(b) GDPR. |
| Modtagere | De nævnte tjenester modtager ingen personoplysninger om vores Kunder, for så vidt en virksomheds domænenavne og serveradresser ikke er personoplysninger; for enkeltmandsvirksomheder kan domænenavnet være en personoplysning. Medlemmer af arbejdsområdet ser domænet. |
| Tredjeland | Forespørgslerne kan nå tjenester i tredjelande (f.eks. registeropslag, blokeringslister). Der overføres kun det, der er angivet i rækken »Forespørgsler til tredjeparter«. |
| Opbevaring | Indtil domænet slettes. fe_domain_loeschen() sletter derefter straks kontrolresultater, formularer, fund, billeder, rapporter, job, alarmmål og alarmlog, hændelser, Telegram-koder, leveringer, puls, sårbarheder og beviser; via fremmednøgler overvågede formularer, browserkørsler, testkonto og formulartællere; hostens plugin-data, hvis intet andet domæne henviser til den. Desuden slettes domænets scriptoversigt og scriptændringer; de har ingen egen opbevaringsperiode (afsnit 6.4). Kontrolresultater højst 13 måneder, det seneste bevares. |
| TOM'er | Afsnit 8. Overvågning af eksponerede filer og versioner kun for verificerede domæner, højst én forespørgsel pr. sti, kun de første 8 KB; at afsøge tredjeparters stier uopfordret ville være et angrebsværktøj. |
B.16 Alarmer, hændelser og eskalering over for kontoindehaveren
| Felt | Oplysning |
| Formål | At informere Kunden om fejl og ændringer, overholde vedligeholdelsesvinduer, kvittere for og eskalere hændelser. Hvor målene er tredjeparter, handler vi på Kundens vegne (A.3); hvor det er kontoindehaveren selv, er det beskrevet her. |
| Kategorier af registrerede | Kontoindehavere og teammedlemmer som modtagere. |
| Kategorier af personoplysninger | Som A.3. Meddelelser vises på kontoindehaverens sprog. |
| Retsgrundlag | Art. 6(1)(b) GDPR. |
| Modtagere | Mailtjenesteudbyder; valgte chattjenester (4.1). |
| Tredjeland | Afhænger af kanalen (4.1). |
| Opbevaring | Som A.3: leveringslog 90 dage, samlede meddelelser 30 dage efter levering, hændelser indtil løsning og derefter 180 dage. Alarmmål sammen med domænet. |
| TOM'er | Afsnit 8. |
B.17 Månedsrapport til konti
| Felt | Oplysning |
| Formål | Den 1. i hver måned fra kl. 08.00 (indhentning indtil den 3.) én e-mail pr. konto, der dækker alle dens domæner: niveau, score og ændring, alarmer, blokerede bots, e-mailafsendelse, sammenligningsværdi. |
| Kategorier af registrerede | Aktive kontoindehavere, der har månedsrapporten slået til. |
| Kategorier af personoplysninger | E-mailadresse, sprog, nøgletal for domænerne. |
| Retsgrundlag | Art. 6(1)(b) GDPR (en del af tjenesten). Kan frameldes i indstillingerne; kan slås fra centralt. |
| Modtagere | Mailtjenesteudbyder (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tredjeland | Via mailtjenesteudbyderen. |
| Opbevaring | Ingen separat opbevaring; e-mailen forbliver i udbakken i 30 dage (B.25). |
| TOM'er | Afsnit 8. |
B.18 Badge og offentlig bekræftelsesside
| Felt | Oplysning |
| Formål | En Kunde kan indlejre et badgebillede på sit websted og linke det til en offentlig bekræftelsesside. Badget viser kun »Beskyttet«, hvis domænet er verificeret, overvågningen kører, og den seneste gennemførte kontrol højst er 45 dage gammel og gav resultatet »Beskyttet« eller »Delvist beskyttet«; ellers viser det neutralt »Kontrol af kontaktformular«. Bekræftelsessiden angiver niveau og dato, ingen enkelte fund. |
| Kategorier af registrerede | Besøgende på Kundens websted, hvis browser indlæser billedet; besøgende på bekræftelsessiden. |
| Kategorier af personoplysninger | Når billedet indlæses: IP-adresse, tidspunkt, anmodet adresse, henvisende side og browseridentifikator i webserverloggen (B.1). Billedadressen starter ingen session, sætter ingen cookie og skriver ikke til loggen over sidevisninger. Bekræftelsessiden er en almindelig side (B.2, B.3). |
| Retsgrundlag | Art. 6(1)(f) GDPR. Interesse: at levere billedet og holde driften sikker. Om Kunden og vi er fælles dataansvarlige for overførslen af den besøgendes IP-adresse i henhold til retspraksis om indlejret tredjepartsindhold, og om der kræves en ordning efter Art. 26, er et åbent spørgsmål til den juridiske gennemgang. Kunden modtager et tekstforslag til sin privatlivspolitik. |
| Modtagere | Ingen. |
| Tredjeland | Ingen. |
| Opbevaring | 14 dage (webserverlog). Billedet caches i én time. Når badget slås fra, ophører identifikatoren med at være gyldig. |
| TOM'er | Afsnit 8. |
B.19 Bevislog og tidsstempel
| Felt | Oplysning |
| Formål | Én log pr. domæne og måned (betalte planer): hvad der blev kontrolleret, med hvilket resultat, hvad der blev rapporteret, og hvad der ændrede sig, som dokumentation i forbindelse med ansvarlighed, over for forsikringsselskaber eller ved leverandørrevisioner. Hver version får et kontrolnummer; en offentlig side bekræfter domæne, periode og nøgletal, ingen detaljer. Siden 7. oktober 2026 har en tidsstemplingsmyndighed i henhold til RFC 3161 bekræftet tidspunktet. |
| Kategorier af registrerede | Kunder; indirekte personer, der kan være nævnt i loggen som godkendere eller som dem, der har kvitteret. |
| Kategorier af personoplysninger | Domæne, måned, kontrolnummer, indholdshash (SHA-512), resumé og data i loggen, tidsstempelsvar, tidsstemplingsmyndighed og tidspunkt, mislykkede forsøg (proof_docs). |
| Retsgrundlag | Art. 6(1)(b) GDPR. |
| Modtagere | Tidsstemplingsmyndigheden (standard Certum, reserve DigiCert) modtager kun hashen af loggen, ikke dens indhold. Offentligt: nøgletal via bekræftelsessiden. Kunden og enhver, som Kunden giver loggen eller kontrolnummeret. |
| Tredjeland | Ingen overførsel af personoplysninger: en hash gør det ikke muligt at slutte noget om indholdet. Reservemyndigheden har hjemsted i USA. |
| Opbevaring | Indtil domænet slettes (fe_domain_loeschen()). Tidsstemplet er ikke et kvalificeret tidsstempel i henhold til eIDAS. |
| TOM'er | Afsnit 8. |
B.20 Plugin og udvidelse: kontrol, forbindelse og overførsel
| Felt | Oplysning |
| Formål | WordPress-pluginet og TYPO3-udvidelsen kan anmode om en kontrol (også uden konto), forbinde sig til en konto (installationen gælder som bevis for kontrol med ét klik i kontoen), låse beskyttelsesfunktioner op, rapportere tal dagligt (A.9) og straks rapportere e-mailfejl og vedligeholdelsestilstand. |
| Kategorier af registrerede | Kunder; dem, der driver websteder og bruger pluginet uden konto. |
| Kategorier af personoplysninger | Pr. host: plugin- og CMS-version, antal kontroller, seneste rapportidentifikator, hash af forbindelseshemmeligheden, første og seneste kontakt (plugin_sites). Engangsforbindelseskoder som hash med udløb (plugin_connect_tokens). Et bureaus udrulningskoder som hash med præfiks, mærkat, anvendelser, oprettende person (workspace_connect_codes). Forespørgselslog med IP-adressen på den kaldende server (B.4). Plugin-nøglen er offentligt synlig i webstedets head; den er en hash af hemmeligheden, og selve hemmeligheden gemmes kun som hash og returneres aldrig. |
| Retsgrundlag | Art. 6(1)(b) GDPR (konto); uden konto (f) (anmodet kontrol, forebyggelse af misbrug). |
| Modtagere | Ingen. |
| Tredjeland | Ingen. |
| Opbevaring | En hosts data slettes, så snart intet domæne længere henviser til den; rækken for et plugin uden konto først efter 90 dage uden kontakt (natlig sletningskørsel, delen »orphan_hosts«). Engangskoder én dag efter udløb. Udrulningskoder sammen med arbejdsområdet. |
| TOM'er | Afsnit 8. Siden 27. september 2026 accepterer serveren kun nøglepar, der er bundet til webstedet; ældre, ubundne forbindelseshemmeligheder blev slettet. |
B.21 Sværmbeskyttelse
| Felt | Oplysning |
| Formål | Fælles spamforsvar: forbundne websteder rapporterer domænerne for links i beskeder, som deres beskyttelseslag har stoppet. Et domæne, der optræder på mindst tre websteder med mindst fem hits inden for syv dage, kommer på en liste, der sendes tilbage til alle forbundne websteder; deres beskyttelseslag flytter beskeder med sådanne links i karantæne, aldrig ud i glemslen. |
| Kategorier af registrerede | Indehavere af de rapporterede linkdomæner, for så vidt de er fysiske personer (f.eks. den, der driver et spamwebsted i eget navn). Ikke afsendere og modtagere af beskederne: adresser, tekster og navne rapporteres ikke. |
| Kategorier af personoplysninger | Signaler: type, domæne, rapporterende host, dag, hits (swarm_signals). Liste: type, domæne, antal websteder og hits, tidspunkter (swarm_list). Store tjenester, vores Kunders domæner og undtagelser fastsat af operatøren kommer aldrig på listen. |
| IP-netværk | Deling af IP-netværk (/24, /48) er forberedt. Den er slået fra, og pluginet rapporterer ingen; den slås først til efter en juridisk gennemgang, fordi IP-adresser er personoplysninger. |
| Retsgrundlag | Art. 6(1)(f) GDPR. Interesse: at beskytte alle Kunders formularer mod spambølger. Afvejning: kun domæner, minimumstærskler mod forgiftning, intet tab af beskeder, fjernelse mulig når som helst. |
| Modtagere | Alle forbundne websteder (listen over domæner). |
| Tredjeland | Afhænger af, hvor de forbundne websteder befinder sig; listen kan også nå websteder uden for EØS. Den udgør kun personoplysninger i grænsetilfælde (domæner tilhørende fysiske personer). Overførselsgrundlaget efter kapitel V i GDPR for disse tilfælde mangler endnu at blive fastlagt (åbent spørgsmål til den juridiske gennemgang). |
| Opbevaring | Signaler 30 dage (daglig sværmkørsel fra kl. 04.00, cfg/swarm_lib.php). Listen genberegnes dagligt; det, der ikke længere når tærsklen, falder ud. |
| TOM'er | Afsnit 8. |
B.22 API-nøgler, programmeringsgrænseflade og MCP-server
| Felt | Oplysning |
| Formål | Adgang for Kundens egne værktøjer (REST API, Zapier, Make, MCP-server til AI-assistenter) til Kundens domæner, kontroller og hændelser. |
| Kategorier af registrerede | Kunder, der opretter nøgler. |
| Kategorier af personoplysninger | Nøgle kun som hash, præfiks, mærkat, tidspunkter for oprettelse, seneste brug og tilbagekaldelse (api_keys). Kald pr. minut (api_usage). |
| Retsgrundlag | Art. 6(1)(b) GDPR. |
| Modtagere | Det værktøj, som Kunden udstyrer med nøglen; Kunden bestemmer det. |
| Tredjeland | Afhænger af Kundens værktøj. |
| Opbevaring | Nøgler indtil tilbagekaldelse, straks sammen med kontoen; nøgler uden konto (ældre data) om natten. Kaldtællere efter én dag (lejlighedsvis ryddet op ved et kald). |
| TOM'er | Afsnit 8. |
B.23 reCAPTCHA og vores egen formularbeskyttelse
| Felt | Oplysning |
| Formål | Forsvar mod automatiseret adgang til vores egne formularer: gratis kontrol, header-værktøj, opt-out, login, registrering, glemt og nulstilling af adgangskode, support og kontakt. Derudover vores egen beskyttelse uden tredjeparter: fælde (skjult felt), signeret tidskontrol og CSRF-token. Siden 29. oktober 2026 desuden vores formularbeskyttelse formconfirmed (beregningsbevis og engangskontroltoken) ved den gratis kontrol, registreringen, login og »glemt adgangskode«. |
| Kategorier af registrerede | Personer, der indsender disse formularer. |
| Kategorier af personoplysninger | Hos Google: IP-adresse, browser- og enhedsdata, adfærdsdata, Google-cookies. Hos os: Googles vurdering (score og handling) kun i kontroløjeblikket, uden lagring, heller ikke når en indsendelse afvises. Ved vores egen formularbeskyttelse: IP-adresse (gemmes kun forkortet og hashet), side, tidspunkter, fældefelt udfyldt ja/nej; intet indhold. |
| Tidspunkt | Googles script indlæses først, når en beskyttet formular indsendes, ikke når siden åbnes. Vores egen formularbeskyttelse henter sin opgave, når siden åbnes, og regner, så snart formularen bruges. På udviklingssystemet er reCAPTCHA slået fra. |
| Retsgrundlag | Art. 6(1)(f) GDPR. Interesse: beskyttelse mod bots, især for den gratis kontrol, som ellers kunne bruges mod tredjeparters websteder. Om adgangen til terminaludstyret kræver samtykke efter § 25 TDDDG eller Art. 399 PKE, selv om scriptet først indlæses ved indsendelse, er et åbent spørgsmål til den juridiske gennemgang. Vores egen formularbeskyttelse sætter ingen cookies, gemmer intet i browseren og danner intet fingeraftryk; den skal på sigt erstatte reCAPTCHA. |
| Modtagere | Google Ireland Limited; Google LLC. Ved vores egen formularbeskyttelse ingen. |
| Tredjeland | USA (kun reCAPTCHA). Grundlag: certificering under EU-US Data Privacy Framework eller standardkontraktbestemmelser; skal dokumenteres nærmere. |
| Opbevaring | reCAPTCHA: ingen opbevaring hos os; hos Google efter Googles regler. Egen formularbeskyttelse: hashet identifikator 1 time, brugte kontroltokens højst 11 minutter, kontrolresultater uden IP-adresse 30 dage. |
| Nedbrud | Hvis Google ikke svarer inden for tre sekunder eller svarer ubrugeligt, afvises indsendelsen; det samme gælder et tomt token og et svar for en anden handling end formularens. Kontrollen springes kun over, når reCAPTCHA er slået fra. Ved vores egen formularbeskyttelse afvises en indsendelse uden gyldigt kontroltoken; hvis tjenesten ikke kunne nås for opgaven, tillades den. |
| TOM'er | Afsnit 8. |
B.24 Support- og kontaktformular
| Felt | Oplysning |
| Formål | Modtagelse og besvarelse af henvendelser via supportvinduet og kontaktsiden. Begge bruger samme rute og samme tabel. |
| Kategorier af registrerede | Personer, der henvender sig, logget ind eller ej. |
| Kategorier af personoplysninger | Konto (hvis logget ind; så gælder kontoens adresse, ikke den indtastede), e-mailadresse, årsag fra en fast liste, tekst på op til 4.000 tegn, status, fuld IP-adresse, land, browseridentifikator, henvisende side (kun egne stier), sprog, tidspunkter for modtagelse og svar (support_requests); post i aktivitetsloggen (uden tekst); kvittering for modtagelse til den, der henvender sig, i udbakken (B.25), med teksten på op til 2.000 tegn kun for afsendere, der er logget ind, og uden teksten for henvendelser foretaget uden login. |
| Retsgrundlag | Art. 6(1)(b) GDPR, hvor henvendelsen vedrører en kontrakt; ellers (f). Fuld IP-adresse: (f) (grænse på tre henvendelser pr. time og adresse, forebyggelse af misbrug). |
| Modtagere | Mailtjenesteudbyder (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) til kvittering og svar. Telegram modtager et fast signal uden variabel (»der er en ny supportanmodning«) og dermed ingen personoplysninger. |
| Tredjeland | Via mailtjenesteudbyderen. |
| Opbevaring | 24 måneder (natlig sletningskørsel, delen »support«); manuelt tidligere. Når en konto slettes, forbliver henvendelserne indtil udløbet af opbevaringsperioden (afsnit 6.4). |
| TOM'er | Afsnit 8. reCAPTCHA, vores egen formularbeskyttelse, hastighedsbegrænsning. |
B.25 Afsendelse af e-mail (udbakke)
| Felt | Oplysning |
| Formål | Transaktionelle e-mails: bekræftelse af registrering og af nye e-mailadresser, nulstilling af adgangskode, invitationer, alarmer, månedsrapporter, portalbekræftelser og -rapporter, kvitteringer og svar fra support, påmindelser om prøveperioden og opsætningen, driftsmeddelelser til operatørerne. Ingen reklame, ingen e-mails til personer, der ikke selv har tilmeldt sig eller er angivet som modtagere af Kunden. |
| Kategorier af registrerede | Modtagere af disse e-mails. |
| Kategorier af personoplysninger | Modtageradresse, emne, fuldstændigt indhold, svaradresse, formål, afsendelsesrute, status, fejl, forsøg, tidspunkter (mail_outbox). Indholdet kan omfatte bekræftelses- og nulstillingslinks med gyldige identifikatorer. |
| Retsgrundlag | Art. 6(1)(b) GDPR; for driftsmeddelelser (f). |
| Modtagere | Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (afsendelse); kontoindehaveren ser sine afsendte e-mails i dataeksporten (uden indhold). |
| Tredjeland | Afhænger af, hvor mailtjenesteudbyderen behandler data; kontrakt og overførselsgrundlag mangler endnu at blive dokumenteret (afsnit 4). |
| Opbevaring | 30 dage (om natten, srv/cron_status.php). Denne periode er bevidst den korteste af alle logge: en lang afsendelseslog ville være en samling af gyldige nøgler. Statuskørslen kontrollerer hvert femte minut, om et nyt forsøg skal foretages. |
| Status | E-mailafsendelse skal være sat op før lanceringen. Indtil mailtjenesteudbyderen med hjemsted og grundlag er afklaret, viser de juridiske tekster en markering. |
| TOM'er | Afsnit 8. Mislykkede e-mails forsøges igen med stigende intervaller og opgives efter et maksimalt antal forsøg. |
B.26 Betalinger og fakturering
| Felt | Oplysning |
| Formål | Indgåelse og administration af abonnementer (månedligt eller årligt forud), 14 dages prøveperiode uden kort med en påmindelse tre dage før udløbet, betaling via faktura for årsabonnementer (slået fra som standard), oplåsning via hoster- og partnerkoder uden betaling, fakturering, opbevaring af skattemæssige hensyn. |
| Kategorier af registrerede | Kunder. |
| Kategorier af personoplysninger | Hos Stripe: e-mailadresse, navn, faktureringsadresse, momsnummer, betalingsdata, fakturaer; som metadata vores konto-ID og planen. Hos os: Stripe-kunde- og abonnements-ID, plan, status, periodens udløb, opsigelse ved periodens udløb (users); modtagne Stripe-hændelser kun med identifikator, type, status og tidspunkter, uden indhold (stripe_events); indløsninger af hosterkoder med konto, kampagne og udløb (bundle_redemptions). Kortdata når aldrig frem til os. |
| Kilde | Kunden i Stripes checkout; hændelser fra Stripe. |
| Retsgrundlag | Art. 6(1)(b) GDPR; for opbevaring af skattemæssige hensyn (c). |
| Modtagere | Stripe Payments Europe Limited (Irland); Stripe, Inc. (USA). For dele af betalingsbehandlingen handler Stripe på eget ansvar; den præcise rollefordeling indgår i den juridiske gennemgang. |
| Tredjeland | USA via Stripe, Inc.; grundlag: Data Privacy Framework eller standardkontraktbestemmelser i henhold til Stripes vilkår. |
| Opbevaring | Faktureringsfelter sammen med kontoen; et løbende abonnement afsluttes, før kontoen slettes. Fakturaer og regnskabsbilag efter polsk skatteret i fem år fra udgangen af det år, hvor fristen for skattebetalingen udløb; de opbevares hos Stripe og kan hentes i Stripes kundeportal. Stripe-hændelser og kodeindløsninger har ingen opbevaringsperiode (afsnit 6.4). |
| TOM'er | Afsnit 8. Stripe-hændelser accepteres kun med gyldig signatur; hver hændelse behandles én gang. |
B.27 Sikkerhedskopier
| Felt | Oplysning |
| Formål | Gendannelse efter en fejl: fejlagtig sletning, beskadiget migrering. |
| Kategorier af registrerede | Alle, hvis data findes i databasen. |
| Kategorier af personoplysninger | Fuldstændigt, komprimeret dump af applikationsdatabasen. Skærmbilleder og logofiler opbevares uden for databasen og er ikke en del af denne sikkerhedskopi. Adgangsoplysninger til testkonti er kun indeholdt i den som krypteret tekst (A.5). |
| Fremgangsmåde | Hver nat kl. 03.00 efter sletningskørslen, så sikkerhedskopien ikke tager det med, som opbevaringsperioderne netop har slettet. Dumpet bevares kun, når dets indhold er kontrolleret (exitkode, antal tabeller, sidste linje). Om søndagen indlæser en gendannelsestest den seneste sikkerhedskopi i en midlertidig database og sammenligner den tabel for tabel. Hvis noget mislykkes, sendes et signal og en e-mail til operatørerne. |
| Retsgrundlag | Art. 6(1)(f) GDPR sammenholdt med Art. 32(1)(c). |
| Modtagere | Ingen. |
| Tredjeland | Ingen. |
| Opbevaring | 14 dage; ældre dumps fjernes først efter en vellykket ny sikkerhedskopi (cfg/backup_lib.php). Sletninger, der finder sted i dette tidsrum, slår først igennem i sikkerhedskopien, når den udløber; hvis data gendannes fra en sikkerhedskopi, gennemføres sletningsanmodninger igen bagefter. |
| Placering | Sikkerhedskopierne opbevares i øjeblikket samme sted som databasen og er ikke krypteret separat; en krypteret kopi på en anden placering er planlagt (afsnit 8.1 og 10). |
| TOM'er | Afsnit 8. |
B.28 Fejllog og fejlalarm
| Felt | Oplysning |
| Formål | At finde og rette fejl, før en Kunde rapporterer dem. Nye fejltyper og fejlbølger rapporteres til operatørerne, plus en daglig oversigt fra kl. 08.00. |
| Kategorier af registrerede | Brugere, hvis forespørgsel forårsager en fejl; indirekte personer, hvis data optræder i en fejlmeddelelse. |
| Kategorier af personoplysninger | Niveau, kilde, meddelelse, kontekst som JSON, sessionens konto-ID, tidspunkt (error_logs). Fejltyper: fingeraftryk, mønster (hvorfra e-mailadresser, adresser, numre og identifikatorer er fjernet), én uændret eksempelmeddelelse på op til 2.000 tegn, første og seneste forekomst, antal (error_kinds). |
| Retsgrundlag | Art. 6(1)(f) GDPR (driftssikkerhed, Art. 32). |
| Modtagere | Operatørerne pr. e-mail via mailtjenesteudbyderen: ved en ny fejltype kilde og råtekst af meddelelsen på op til 400 tegn (ikke renset) samt den daglige oversigtsmail; ved en fejlbølge sendes kun Telegram-signalet. Telegram modtager kun faste sætninger uden variabler (»Der er opstået en ny fejltype«, »Mange fejl på kort tid«). |
| Tredjeland | Via mailtjenesteudbyderen. |
| Opbevaring | Fejllog 90 dage (om natten). Fejltyper uden opbevaringsperiode (afsnit 10). Fejlalarmen er slået til i produktionssystemet og fra i udviklingssystemet. |
| TOM'er | Afsnit 8. |
B.29 Driftssignaler og statusovervågning
| Felt | Oplysning |
| Formål | At opdage nedbrud: hvert femte minut en kontrol af komponenterne (forside, database, diskplads, scannerens hjerteslag, kø-efterslæb), statusside, signal ved fejl og ved afblæsning, hjerteslag til en ekstern overvågningstjeneste, så selv et fuldstændigt nedbrud bliver opdaget; efterslæb foran scanneren. |
| Kategorier af registrerede | Som regel ingen. |
| Kategorier af personoplysninger | Ingen. Daglige rækker pr. komponent med antal kontroller og seneste fejl (system_status_logs), scannerens hjerteslag (scanner_heartbeat), daglige nøgletal uden personhenførbarhed (daily_stats). Signalerne til Telegram er faste sætninger uden variabler; hjerteslaget er en forespørgsel uden indhold. |
| Retsgrundlag | Ikke relevant, da der ikke er tale om personoplysninger; for en sikkerheds skyld Art. 6(1)(f). |
| Modtagere | Telegram (faste sætninger); den eksterne overvågningstjeneste (kun forespørgslen); operatørerne pr. e-mail. |
| Tredjeland | Telegram uden for EU; der overføres ingen personoplysninger. |
| Opbevaring | Statusrækker 400 dage (om natten). |
| TOM'er | Afsnit 8. |
B.30 Opt-out – udelukkelse af et domæne
| Felt | Oplysning |
| Formål | Enhver kan permanent udelukke et hvilket som helst domæne fra kontroller uden bevis; spærringen træder straks i kraft for alle kontrolruter (gratis kontrol, plugin uden konto, undersøgelse, kontrol af potentielle kunder, header-værktøj) og også for domæner tilhørende betalende Kunder med bevis for kontrol; deres igangværende overvågning ophører ved den næste planlagte kontrol. Den gælder for domænet og dets www-variant, ikke for andre underdomæner. Den ophæves kun af os, efter anmodning og mod bevis. For at misbrug (f.eks. en konkurrent, der spærrer andres domæner) kan opdages og omgøres, logges spærringen. |
| Kategorier af registrerede | Personer, der udelukker et domæne. |
| Kategorier af personoplysninger | Domæne, frivillig begrundelse på op til 250 tegn, kilde, IP-adresse, land, browseridentifikator, tidspunkt; ved ophævelse tidspunkt, den person, der ophæver spærringen, og begrundelse (blocklist). Forespørgselslog som B.4. |
| Retsgrundlag | For udelukkelsen Art. 6(1)(f) GDPR. Interesse: permanent og på tværs af alle kontrolruter at efterkomme ønsket om, at et domæne ikke kontrolleres. Hvis den person, der udelukker domænet, selv er registreret, efterkommer udelukkelsen samtidig vedkommendes indsigelse efter Art. 21 (Art. 6(1)(c)). For adresse, land og browseridentifikator (f) (opdagelse af misbrug). |
| Modtagere | Google (reCAPTCHA, B.23). |
| Tredjeland | USA via reCAPTCHA. |
| Opbevaring | IP-adresse, land og browseridentifikator efter 12 måneder (natlig sletningskørsel, delen »optout_ip«). Selve udelukkelsen forbliver permanent, så den har virkning. |
| TOM'er | Afsnit 8. Mange spærringer fra ét land inden for kort tid genererer en anomali (B.4). |
B.31 Påmindelse efter registrering
| Felt | Oplysning |
| Formål | En enkelt e-mail to til 14 dage efter registreringen til bekræftede konti uden bekræftet domæne: »Tilføj websted« eller »Bekræft domæne«. Intet tilbud, ingen pris, ingen opgradering; med en bemærkning om, at den ikke sendes igen. Hverdage kl. 09.00 til 18.00, højst 50 pr. kørsel. |
| Kategorier af registrerede | Nye kontoindehavere. |
| Kategorier af personoplysninger | E-mailadresse, sprog, afsendelsestidspunkt (feltet »påmindelse sendt« i users), domæne og bekræftelsesstatus. |
| Retsgrundlag | Art. 6(1)(b) GDPR (henvisning til opsætning af egen konto). Om e-mailen gælder som en meddelelse om kontraktforholdet eller som kommerciel information, der ville kræve samtykke (Art. 10 UŚUDE, den polske lov om levering af tjenester ad elektronisk vej (ustawa o świadczeniu usług drogą elektroniczną); Art. 398 PKE; § 7 UWG), er et åbent spørgsmål til den juridiske gennemgang; operatøren kan slå den fra centralt. |
| Modtagere | Mailtjenesteudbyder (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tredjeland | Via mailtjenesteudbyderen. |
| Opbevaring | Tidspunktet bevares, så længe kontoen findes; e-mailen 30 dage i udbakken. |
| TOM'er | Afsnit 8. Tidspunktet sættes før afsendelsen, så en afbrydelse ikke udløser en ny e-mail. |
B.32 Telegram-bot til Kundealarmer
| Felt | Oplysning |
| Formål | En Telegram-chat tilknyttes som alarmmål: Kunden modtager et link til vores bot med en engangskode; når modtageren trykker på »Start«, læser vores server koden fra de nye beskeder til botten og gemmer chat-ID'et. Det kræver intet åbent endepunkt hos os (webhook). |
| Kategorier af registrerede | Kunder og de personer, hvis Telegram-chat tilknyttes. |
| Kategorier af personoplysninger | Engangskode, domæne, oprettende konto, hændelser, leveringstilstand, chat-ID, tidspunkter (telegram_links); chat-ID'et som mål (alerts). Telegram leverer yderligere profiloplysninger med beskeden; kun koden og chat-ID'et evalueres og gemmes. |
| Retsgrundlag | Art. 6(1)(b) GDPR; for tredjeparter som modtagere A.3. |
| Modtagere | Telegram. |
| Tredjeland | Uden for EU, ingen afgørelse om tilstrækkeligt beskyttelsesniveau; valget træffes af Kunden (4.1). Grundlag og oplysning er åbne spørgsmål til den juridiske gennemgang. |
| Opbevaring | En kode er gyldig i 30 minutter; tilknytningsrækker slettes efter én dag, når en ny kode oprettes, åbne koder sammen med kontoen og domænet. Chat-ID'et som mål, indtil alarmmålet eller domænet slettes. |
| TOM'er | Afsnit 8. |
B.33 Partnerprogram og oplåsningskoder
| Felt | Oplysning |
| Formål | En konto kan henvise nye Kunder via en henvisningskode og modtager provision af deres betalte fakturaer i et begrænset antal måneder. Koden følger med i adressen indtil registreringen; der sættes ingen cookie. Hostere og partnere kan udstede koder, der låser en plan op for en periode uden betaling; en uge før udløbet modtager Kunden en påmindelse. |
| Status | Partnerprogrammet er slået fra som standard, indtil partnervilkårene foreligger. |
| Kategorier af registrerede | Partnere og henviste Kunder. |
| Kategorier af personoplysninger | Henvisningskode, henvisende partner og tidspunkt for henvisningen (i users); provision med partner, Kunde, Stripe-faktura-ID, beløb, valuta, provision, status, tidspunkter (partner_commissions). Oplåsning med plan, udløb, kilde, påmindelse (i users); kampagner og indløsninger (bundle_campaigns, bundle_redemptions). |
| Retsgrundlag | Art. 6(1)(b) GDPR (partneraftale); for Kunden (f) (afregning af provisionen uden videregivelse af Kundens data til partneren ud over provisionsbeløbet); skattemæssige registreringer (c). |
| Modtagere | Partneren ser sine provisioner. |
| Tredjeland | Ingen. |
| Opbevaring | Henvisning og oplåsning sammen med kontoen. Provisioner og indløsninger har ingen opbevaringsperiode i koden; som regnskabsbilag er provisioner omfattet af opbevaring af skattemæssige hensyn (afsnit 6.4). |
| TOM'er | Afsnit 8. |
B.34 Kontaktpunkt for sårbarhedsrapporter
| Felt | Oplysning |
| Formål | Modtagelse af rapporter om sårbarheder i formexposed i henhold til reglerne på siden Sikkerhed og i /.well-known/security.txt. |
| Kategorier af registrerede | Rapporterende personer; personer, hvis data en rapport indeholder som bevis. |
| Kategorier af personoplysninger | E-mailadresse, navn, indholdet af rapporten og vedhæftede filer, som den rapporterende person sender dem. Rapporten når os pr. e-mail til den adresse, der er angivet dér; applikationen gemmer den ikke. |
| Retsgrundlag | Art. 6(1)(f) GDPR (tjenestens sikkerhed, Art. 32); hvis en rapport indeholder tredjeparters personoplysninger som bevis, ligeledes (f) med det formål at lukke sårbarheden. |
| Modtagere | Mailtjenesteudbyder og, indtil postkassen er sat op, domænevideresendelsen hos Namecheap (afsnit 4). |
| Tredjeland | Via mailtjenesteudbyderen og, indtil omstillingen, videresendelsen. |
| Opbevaring | Der er hverken fastsat eller teknisk håndhævet nogen opbevaringsperiode (afsnit 10). Operatøren mangler endnu at fastsætte perioden; en nærliggende løsning ville være at slette tredjeparters bevismateriale, når sårbarheden er lukket, og at behandle korrespondancen som supporthenvendelser. |
| TOM'er | Afsnit 8. |
B.35 Feedback på en rapport
| Felt | Oplysning |
| Formål | Modtagelse af feedback under en rapport (»Er der noget forkert i denne rapport?«) for at finde fejl i formulargenkendelsen. Superadministratoren klassificerer den (ny, bekræftet, rettet, afvist) og kan downloade rapportens kontroldata som testcase (formularer med felter, begrundelser og fund, uden skærmbilleder og uden aktivt sendte tekster). |
| Kategorier af registrerede | Personer, der ser en rapport, logget ind eller ej. |
| Kategorier af personoplysninger | Kategori og kontrol fra faste lister, sideadresse på op til 500 tegn, tekst på op til 1.000 tegn, sprog, tidspunkt, rapportidentifikator, kontrol, host; kontoidentifikator, hvis logget ind; HMAC-SHA256 af IP-adressen med en hemmelig nøgle til begrænsningen; status, sagsbehandler, behandlingstidspunkt (report_feedback). Aktivitetslog: statusændringer og downloads af en testcase. Ingen e-mailadresse, ingen IP-adresse i klartekst. |
| Retsgrundlag | Art. 6(1)(f) GDPR (at finde og rette genkendelsesfejl; begrænsning mod misbrug). |
| Modtagere | Ingen. |
| Tredjeland | Ingen. |
| Opbevaring | 24 måneder (natlig sletningskørsel, delen »report_feedback«); kontrolsummen af IP-adressen ryddes efter 2 dage (delen »report_feedback_ip«); straks, når en konto slettes. Downloadede testcases indeholder ingen data om den rapporterende person. |
| TOM'er | Afsnit 8. Egen formularbeskyttelse (fælde, signeret tid, CSRF), højst 5 rapporter pr. time og 20 pr. dag pr. kontrolsum, 10 pr. rapport; kun læsbar for superadministratorer. |
6. Opbevaring – hvad den natlige sletningskørsel omfatter, og hvad den ikke omfatter
Der findes automatisk sletning, og den har et fast sted. En statuskørsel (srv/cron_status.php) startes hvert femte minut via webserverens crontab, på produktionssystemet såvel som på udviklingssystemet. Den kontrollerer komponenterne, henter leveringskontrollens mail, planlægger kontroller og sender alarmer. Én gang om dagen, i tidsvinduet fra kl. 03.00 til 03.04, sletter den i henhold til opbevaringsperioderne og opretter derefter sikkerhedskopien. Siden 27. september 2026 har den desuden kaldt opbevaringskørslen i cfg/fristen_lib.php (fe_fristen_lauf()), hvis dele kører uafhængigt af hinanden: hvis én fejler, fortsætter de andre, og fejlen registreres i fejlloggen.
Dokumentation for, at kørslen kører: sikkerhedskopistatus på udviklingssystemet viser en vellykket sikkerhedskopi kl. 03.00 den 11. oktober 2026; sikkerhedskopien oprettes i samme blok umiddelbart efter sletningen. Kørslen skriver kun en log pr. slettet tabel til standardoutput, som crontab'en kasserer; der findes ingen permanent registrering af, hvad der blev slettet hvornår (afsnit 10).
De opbevaringsperioder, der vises som pladsholdere, fastsættes i administrationsområdet under indstillingerne for opbevaring. Kørslen læser de samme indstillinger; teksterne viser derfor altid den periode, hvorefter data faktisk slettes.
6.1 Omfattet af den daglige kørsel
| Data | Opbevaringsperiode og udløser | Sted i koden |
Log over sidevisninger (access_logs) | 60 dage | srv/cron_status.php |
Aktivitetslog (audit_logs) | 365 dage | srv/cron_status.php |
Fejllog (error_logs) | 90 dage | srv/cron_status.php |
Udbakke (mail_outbox) | 30 dage | srv/cron_status.php |
Huske-tokens til »Forbliv logget ind« (remember_tokens) | efter udløb (30 dage) | srv/cron_status.php |
Ikke accepterede invitationer (workspace_invites) | efter udløb (14 dage) | srv/cron_status.php |
Loginforsøg (login_attempts); forsøgstællere (auth_attempt_buckets) | 7 dage; tællere, når deres tidsvindue udløber (i øjeblikket 15 minutter, én time for nulstilling af adgangskode og registrering), også ved næste adgang | srv/cron_status.php |
Forespørgselslog for kontroller uden konto (check_throttle) | 7 dage | srv/cron_status.php |
Engangskoder til tilslutning af pluginet (plugin_connect_tokens) | 1 dag efter udløb | srv/cron_status.php |
Løste anomalier (abuse_flags) | 90 dage efter løsning | srv/cron_status.php |
| Udløbne rapporter sammen med kontrolresultat, formularer, fund, billeder og job (kun uden domæne i en konto) | anonyme 30 dage, potentielle kunder 90 dage | fe_reports_aufraeumen() |
Leveringslog for alarmer (alert_log) | 90 dage | fe_alert_log_aufraeumen() |
Statusrækker (system_status_logs) | 400 dage | srv/cron_status.php |
Samtykkeregistreringer for slettede konti (legal_consents) | når kontoen er slettet, og samtykket er 4 år gammelt | srv/cron_status.php |
| Forældreløse data fra slettede domæner: kontrolresultater, job, alarmdata, hændelser, Telegram-koder, leveringer, puls, sårbarheder, beviser, scriptoversigt og scriptændringer | straks ved næste kørsel | fe_fristen_lauf(), delene »orphan_scans«, »orphan_rows« |
| Plugin-data for hosts uden domæne; plugin-række uden konto | straks; række efter 90 dage uden kontakt | delen »orphan_hosts« |
Resultater fra header-værktøjet (header_checks) | i øjeblikket 90 dage | delen »header_checks« |
| Kontrolresultater for et domæne med formularer, fund, billeder, rapporter, job | 13 måneder; det seneste gennemførte pr. domæne bevares | delen »old_scans« |
Browserkørsler, afsluttede browserjob, tidsserier (form_browser_runs, scan_jobs, form_performance) | 13 måneder | delene »browser_runs«, »browser_jobs«, »form_performance« |
Formulartællere (form_metrics), plugin-dagstal og ændringsmeddelelser (plugin_stats, plugin_changes) | 13 måneder | delene »form_metrics«, »plugin_stats« |
Indloggede enheder (login_sessions) | 90 dage efter seneste brug eller tilbagekaldelse | delen »sessions« |
| Accepterede invitationer | 30 dage efter accept | delen »invites« |
Supportanmodninger (support_requests) | 24 måneder | delen »support« |
Feedback på rapporter (report_feedback) | 24 måneder; kontrolsum af IP-adressen 2 dage | delene »report_feedback« og »report_feedback_ip« |
PDF-versioner af rapporter i cachen (var/pdf) | 7 dage | delen »pdf_cache« |
IP-adresse, land og browseridentifikator i opt-out (blocklist) | 12 måneder; udelukkelsen bevares | delen »optout_ip« |
Portalabonnenter (client_subscribers) | ubekræftede 30 dage; afmeldte 3 år | delen »subscribers« |
| Konti, der aldrig er blevet bekræftet, sammen med arbejdsområdet | 30 dage uden login, medmindre et andet medlem er tilknyttet | delen »pending_accounts« |
| API-nøgler uden konto (ældre data) | straks | delen »api_keys« |
6.2 Uden for tidsvinduet kl. 03.00
| Data | Opbevaringsperiode og udløser | Sted i koden |
| Kopier i leveringskontrollens kontrolpostkasse | efter behandling, hvert femte minut | fe_zustellung_abholen() |
Tildelinger i leveringskontrollen (delivery_log) | 180 dage, ved hver hentning | fe_zustellung_abholen() |
Krypteret tekst med adgangsoplysninger til testkonti i job (scan_jobs) | efter kørslen, senest efter én time | scanserver; fe_login_aufraeumen() |
Hændelser (alert_incidents) med deres leveringsforsøg ved eskalering | så længe de ikke er løst; 180 dage efter løsning | fe_vorfaelle_aufraeumen() i cfg/vorfall_lib.php |
Sendte samlede meddelelser (alert_queue) | 30 dage efter levering | cfg/kanal_lib.php |
Sværmsignaler (swarm_signals) | 30 dage, dagligt fra kl. 04.00 | cfg/swarm_lib.php |
Kontroller af potentielle kunder (prospect_checks) | 90 dage, dagligt fra kl. 04.00 | srv/cron_status.php |
Telegram-tilknytningskoder (telegram_links) | 1 dag, når en ny kode oprettes | cfg/kanal_lib.php |
API-kaldtællere (api_usage) | 1 dag, lejlighedsvis ved et kald | cfg/agentur_lib.php |
Løste nedbrud hos udbydere (provider_incidents), sårbarhedscache (vuln_cache) | henholdsvis 90 og 30 dage; ingen personoplysninger | cfg/anbieter_lib.php, cfg/luecken_lib.php |
| Rådata fra undersøgelser | ved offentliggørelse | fe_studie_veroeffentlichen() |
| Sikkerhedskopier | 14 dage, efter en vellykket ny sikkerhedskopi | cfg/backup_lib.php |
| Webserverlogge | 14 dage | systemets logrotation |
6.3 Ved sletning foretaget af Kunden
- Sletning af et domæne (
fe_domain_loeschen()): kontrolresultater med formularer, fund og billedfiler, rapporter, job, alarmmål, leveringslog, kø for samlede meddelelser, hændelser, Telegram-koder, leveringer, puls, sårbarheder, bevislogge, domænet fra kundeportaler med et fast udvalg; via fremmednøgler overvågede formularer med browserkørsler, observationer og tidsserier, testkonto, formulartællere; hostens plugin-data, hvis intet andet domæne henviser til den. Domænets scriptoversigt og scriptændringer slettes også sammen med det; de har ingen egen opbevaringsperiode (afsnit 6.4 og 10). Data uden tilknyttet domæne, der er tilbage fra perioden før 27. september 2026, ryddes af den natlige kørsel (delene »orphan_scans«, »orphan_rows«).
- Sletning af et arbejdsområde (
fe_arbeitsbereich_daten_loeschen()): derudover brand inklusive logo, kundeportaler inklusive abonnenter, udrulningskoder, kontroller af potentielle kunder; samt invitationer og medlemskaber.
- Sletning af en konto: et løbende betalt abonnement hos Stripe afsluttes straks uden refusion; indehaverens egne arbejdsområder overdrages eller slettes; medlemskaber, huske-tokens, enheder, API-nøgler med tællere, åbne Telegram-koder og kontorækken slettes.
- Sletning af en testkonto (
fe_login_loeschen()): den krypterede tekst overskrives, rækken slettes, ventende job ryddes.
6.4 Hvad kørslen ikke omfatter
Denne liste er den vigtigste. Den nævner data, som der ikke findes nogen automatisk opbevaringsperiode for, eller som overlever en sletning.
| Data | Hvad der gælder | Vurdering |
Kontodata inklusive seneste IP-adresse (users) | indtil kontoindehaveren sletter dem; ingen sletning af inaktive konti | kontraktdata; der mangler en regel for permanent inaktive konti uden abonnement |
| Aktivitetslog, sidevisninger, fejllog for en slettet konto | bevares med konto-ID og IP-adresse indtil udløbet af deres opbevaringsperiode | tilsigtet (dokumentation for handlinger også efter ophør); ID'et peger ikke længere på en konto |
| Supportanmodninger fra en slettet konto | bevares i op til 24 måneder med det gamle konto-ID | tilsigtet; ID'et ryddes ikke |
| Samtykkeregistreringer for en slettet konto | indtil samtykket er 4 år gammelt (regnet fra samtykket, ikke fra sletningen af kontoen) | tilsigtet (afsnit B.12) |
Uløste anomalier med IP-adresse (abuse_flags) | indtil nogen løser dem | åbent punkt (afsnit 10) |
Fejltyper med uændret eksempelmeddelelse (error_kinds) | ingen opbevaringsperiode | åbent punkt (afsnit 10) |
Scriptoversigt og scriptændringer (script_inventory, script_changes) | ingen egen opbevaringsperiode; bevares, så længe domænet findes, og slettes sammen med det | åbent punkt (afsnit 10) |
| Abonnenter på tilbagekaldte kundeportaler | indtil arbejdsområdet slettes | åbent punkt (afsnit 10) |
| Tilbagekaldte API-nøgler og udrulningskoder | indtil kontoen eller arbejdsområdet slettes | kun hashes, præfiks og mærkat; ubetydeligt |
Liste over undersøgelseshosts (study_domains), undersøgelser, der aldrig er blevet offentliggjort | ingen opbevaringsperiode | åbent punkt (afsnit 10) |
| Interne kontroller uden domæne og uden rapport (kontrolresultater, formularer, fund, skærmbilleder) | ingen opbevaringsperiode; ingen sletningsrute omfatter dem | åbent punkt (afsnit 10) |
| Provisioner, kodeindløsninger, Stripe-hændelser | ingen opbevaringsperiode | regnskabsmæssig relevans; perioden skal fastsættes efter skatteretten |
Cachet domænealder (domain_age_cache) | ingen opbevaringsperiode | kun domænenavn og registreringsdato |
| Autentificeringsresultat for formularens e-mail med afsenderdomæne | sammen med domænet; overskrives ved hver modtagelse | se A.1 |
| Udelukkelser i opt-out | permanent | tilsigtet; uden varighed har ingen udelukkelse virkning |
| E-mails i rapporteringsstedets postkasse og i den generelle postkasse | ingen teknisk opbevaringsperiode | åbent punkt (afsnit 10) |
6.5 Uden for databasen
- Skærmbilleder opbevares som filer uden for webmappen og slettes sammen med deres kontrolresultat (alle ovenstående sletningsruter sletter også filerne).
- Brandets logofiler slettes, når de udskiftes, og sammen med arbejdsområdet.
- På scanserveren oprettes der pr. job en midlertidig mappe med resultat og billeder; den slettes efter hver kørsel, også efter en fejl.
- Sikkerhedskopier opbevares på webserveren (B.27).
- Webserverlogge med den fulde IP-adresse opbevares i 14 dage (B.1).
7. Automatiske afgørelser, profilering og vurdering
formexposed vurderer websteder, ikke personer. Efter vores vurdering træffer tjenesten ingen afgørelse, som har retsvirkning for en person eller på tilsvarende vis betydeligt påvirker vedkommende (Art. 22(1) GDPR). Der findes dog automatiske vurderinger og automatiske spærringer. Vi oplister dem, så klassificeringen kan efterprøves.
| Mekanisme | Hvad den gør | Hvem den berører |
| Score og bedømmelse af en kontrol | Vægtet sum af manglende beskyttelseslag (CAPTCHA, fælde, token, tidskontrol, ineffektiv CAPTCHA, kendt eksponeret konfiguration), 0 til 100; heraf »Eksponeret«, »Delvist beskyttet« eller »Beskyttet«. Webstedets bedømmelse følger den dårligste kontaktformular, som reglerne (ikke sprogmodellen) har genkendt som sådan; uden kontaktformular gives ingen bedømmelse. Vægtene kan fastsættes i administrationsområdet. | Dem, der driver websteder; for enkeltmandsvirksomheder indirekte en person. Bedømmelsen har ingen retlig konsekvens; den er et fund med dokumentation og vejledning. |
| Klassificering af formulartypen | Først regler, en lokal sprogmodel kun hvis reglerne returnerer »ukendt«. Afgør, om en aktiv testindsendelse er tilladt (kun for en kontaktformular, som reglerne sikkert har genkendt). Formularer, der er klassificeret af sprogmodellen, indsendes aldrig og tæller ikke med i score og bedømmelse. | Kunden og modtagerne af dennes formular-e-mails; beskyttende virkning: i tvivlstilfælde indsendes intet. |
| Badge | Viser kun »Beskyttet« under faste betingelser (B.18), ellers neutral. | Kunde; ingen virkning for besøgende. |
| Grænser og spærringer for den gratis kontrol, header-værktøjet og opt-out | Afviser forespørgsler, hvis grænserne pr. adresse, session, domæne eller system er nået, hvis domænet er for nyt eller af ukendt alder, eller hvis det står på spærrelisten. | Personer, der sender forespørgsler; virkning: en gratis tjeneste nægtes i timer til dage. En administrator kan frigive en adresse; henvendelser via kontaktsiden når frem til et menneske. |
| Anomalier | Mønstre (mange domæner fra én adresse, bølger af forespørgsler, mange afvisninger, mange opt-outs fra ét land, dagsgrænse nået) registreres og rapporteres. De spærrer ikke i sig selv; spærringer følger af grænserne. | Personer, der sender forespørgsler. |
| Loginspærring | Efter i øjeblikket otte mislykkede login fra én adresse inden for 15 minutter afvises login fra denne adresse midlertidigt. Derudover tælles alle loginforsøg, også de vellykkede, pr. konto og IP-adresse (i øjeblikket otte), pr. konto på tværs af alle adresser (betydeligt flere, mod distribueret gætning) og pr. IP-adresse (i øjeblikket 80) inden for 15 minutter, ligesom koder til anden faktor (ti pr. konto inden for 15 minutter); ud over dette afvises forsøg. Mislykkede forsøg fra en anden adresse spærrer derfor ikke længere ejeren ude af en konto. Bekræftelser af adgangskode (fem pr. konto inden for 15 minutter), nulstillingsmails (tre pr. adresse pr. time, med uændret svar), registreringer (ti pr. IP-adresse pr. time) og forsøg på adgangskoden til en kundeportal (ti pr. portal og IP-adresse, 50 pr. portal inden for 15 minutter) begrænses på samme måde. | Personer, der logger ind, registrerer sig eller åbner en kundeportal; virkningen er tidsbegrænset, og nulstilling af adgangskoden er fortsat mulig. |
| reCAPTCHA-tærskel | Afviser indsendelser under en Google-score; tærskel pr. anvendelsessted (i øjeblikket 0,7 for kontrol og opt-out). Svar for en anden handling og indsendelser, hvor Google ikke svarer inden for tre sekunder, afvises også. | Personer, der indsender vores formularer; virkning: et nyt forsøg eller vejen via kontaktsiden. |
| Sværmbeskyttelse | Sætter automatisk et linkdomæne på en liste, når minimumstærskler er nået; beskyttelseslagene på forbundne websteder flytter beskeder med sådanne links i karantæne. | Afsendere af beskeder til Kundesider. Virkning: beskeden tilbageholdes, slettes ikke og kan frigives af den, der driver webstedet. Afgørelsen om beskeden træffes af pluginet hos den, der driver webstedet, på dennes websted, ikke af os. |
| Sammenligningsværdier | »Bedre beskyttet end X % af de kontrollerede websteder«, kun ud fra samlede tal for mindst 20 hosts. | Dem, der driver websteder; ingen virkning. |
Det, der kommer tættest på Art. 22, er pluginets beskyttelseslag på Kundesider, som automatisk tilbageholder indsendelser. Det er behandling foretaget af den, der driver webstedet, på dennes server (A.10). Det sletter intet, men flytter beskeder i karantæne, og den, der driver webstedet, kan frigive enhver besked. Der finder ingen profilering af besøgende sted, hverken dér eller hos os; der findes ingen besøgsidentifikator, der forbinder én besked med en anden.
8. Tekniske og organisatoriske foranstaltninger (Art. 32) – generel beskrivelse
Dette afsnit er den generelle beskrivelse efter Art. 30(1)(g) og (2)(d) GDPR. Den detaljerede version findes på siden Tekniske og organisatoriske foranstaltninger. Hver foranstaltning nedenfor er dokumenteret i koden eller i konfigurationen. Foranstaltninger, der endnu ikke er gennemført, står i samme afsnit (8.1), så beskrivelsen er fuldstændig.
| Område | Gældende foranstaltning |
| Transportkryptering | HTTPS for websted, app og grænseflader; HSTS; session- og huske-token-cookies kun via HTTPS, HttpOnly, SameSite=Lax. |
| Adgangskontrol (autentificering) | Adgangskoder kun som hash, nye med mindst ti tegn og højst 72 byte; loginspærring efter gentagne mislykkede forsøg og forsøgsgrænser pr. konto og IP-adresse samlet, pr. konto og pr. IP-adresse, så mislykkede forsøg fra en anden adresse ikke spærrer ejeren ude; forsøgsgrænser også for bekræftelser af adgangskode, nulstilling af adgangskode (med samme svar og svartid), registreringer og portaladgangskoder; login med to faktorer (TOTP) med krypteret hemmelighed, beskyttelse mod genbrug af koder og hashede gendannelseskoder; ny sessionsidentifikator ved hvert login, identifikatorer, som serveren ikke har udstedt, accepteres ikke; »Forbliv logget ind« ikke for superadministratorer, hvert token kun gyldigt én gang; ændring af e-mailadressen gør et åbent nulstillingslink ugyldigt; enheder kan tilbagekaldes enkeltvis eller alle på én gang; enhedslisten indeholder kun hashen af sessionsidentifikatoren. |
| Adgangskontrol (autorisation) | Roller pr. arbejdsområde (ejer, administrator, læser); tilladelser kontrolleres mod objektet, aldrig mod en identifikator fra formularen; testkonto, »Fix it for me« og aktive kontroller kun for ejere og administratorer; »Vis som Kunde« tidsbegrænset og spærret for kontoændrende handlinger, afslutning logger fuldstændigt ud, tilbagevenden til administrationsområdet kun med adgangskode og anden faktor; invitationer kun gyldige, så længe den inviterende person er ejer eller administrator; adresser på webhooks og chatkanaler vises for læsere kun forkortet til hosten; værtsnavnet på et verificeret domæne kan ikke ændres. |
| Applikationssikkerhed | CSRF-tokens; forberedte databasesætninger (prepared statements); vores egen formularbeskyttelse (fælde, signeret tidskontrol); reCAPTCHA på de offentlige formularer; hastighedsbegrænsning for support, kontroller og grænseflader; kun ét »Fix it for me«-kald pr. arbejdsområde ad gangen, så kvoten også holder ved samtidige forespørgsler; Content Security Policy med beskyttelse mod indramning, som kun lader scripts køre, der bærer frigivelsen (nonce) fra det pågældende svar; IP-adresse fra videresendte headere kun fra vores egen proxy og kun fra den post, som den selv har tilføjet; adgangstokens maskeret i loggen over sidevisninger. |
| Hemmeligheder | API-nøgler, udrulningskoder, plugin-forbindelseshemmeligheder, engangskoder og portaladgangskoder kun som hash; adgangsoplysninger til testkonti asymmetrisk krypteret, privat nøgle kun på scanserveren; webhooks signeret; Stripe-hændelser kun med gyldig signatur. |
| Dataminimering | Leveringskontrollen gemmer intet indhold og ingen fulde afsenderadresser; modtageradresser i formularer kun som domæne; konto-ID'er i scriptadresser erstattes; plugin-tal kun fra faste lister; fejltekster fra e-mailafsendelse kun som kategori; Telegram-signaler uden variabler; billeder fra browserkontrollen med maskeret input; ingen skærmbilleder bag et login. |
| Isolering af scanneren | Hver kontrol i sin egen container: alle Linux capabilities fjernet, ingen rettighedseskalering, skrivebeskyttet filsystem, hukommelses- og procesgrænse, eget netværk; kontrol af målet mod private og lokale netværk før accept og i scanneren, også efter omdirigeringer; service workers blokeret, WebSocket-forbindelser lukket. Forespørgsler fra webserveren (bevis for kontrol, header-værktøj, filsøgning, puls, RDAP, certifikater, webhooks og chatalarmer) kun på de sædvanlige webporte og kun til præcis den kontrollerede adresse, webhooks og chatalarmer kun via HTTPS. |
| Lagring | Skærmbilleder uden for webmappen, kun tilgængelige via rapporten; rapporter på tilfældige adresser med noindex; sikkerhedskopimappen kun læsbar for tjenesten. |
| Tilgængelighed og gendannelse | Natlig sikkerhedskopi med indholdskontrol, ugentlig gendannelsestest, alarm ved fejl; komponentkontrol hvert femte minut med signal og e-mail; eksternt hjerteslag; nødstop for anonyme kontroller; modtryk ved efterslæb. |
| Sporbarhed | Aktivitetslog for login, ændringer, sletninger, supportadgang og godkendelser; fejllog med alarm. |
| Sletning | Opbevaringsperioder ét sted i koden, ud fra de samme indstillinger som teksterne (afsnit 6); sletningskæder for domæne, arbejdsområde og konto med undtagelserne i afsnit 6.4. |
| De registreredes rettigheder | Eksport med ét klik af alle kontodata som fil, baseret på en tilladelsesliste over felter, uden hemmeligheder. |
| Organisation | Administrationsområde kun for konti med superadministratorrettigheder, spærret under »Vis som Kunde«; udviklings- og produktionssystem adskilt, udviklingssystemet bag en ekstra adgangsbarriere; overførsel af juridiske tekster efter godkendelse via et værktøj, der afviser udkast og pladsholdere. |
8.1 Foranstaltninger, der endnu ikke er gennemført
- Ingen kryptering af databasen i hvile (målt den 11. oktober 2026). Undtagelserne er adgangsoplysningerne til testkonti og hemmeligheden til anden faktor, som er krypteret på feltniveau.
- Interne forbindelser er ikke gennemgående krypteret. Forbindelser i vores interne netværk er ikke krypteret overalt. Adgangsoplysninger til testkonti sendes dér kun som krypteret tekst.
- Ingen sikkerhedskopi på en anden placering. Sikkerhedskopierne opbevares i øjeblikket samme sted som databasen og er ikke krypteret separat; en krypteret kopi på en anden placering er planlagt. Indtil da beskytter de mod en forkert sletningskommando, ikke mod tab af placeringen.
- Hærdningen af serveradministrationen er ikke afsluttet. Sikkerheden for den administrative adgang til vores servere lever endnu ikke op til den standard, vi tilstræber for driften; hærdningen fortsætter. Vi offentliggør ikke detaljer, fordi de ville hjælpe en angriber; vi stiller dem til rådighed for en tilsynsmyndighed efter anmodning.
- Ingen funktionel læselog i administrationsområdet. Skrivehandlinger registreres i aktivitetsloggen; hvem der blot har set hvilken supportanmodning eller hvilken rapport, kan kun fastslås ud fra loggen over sidevisninger (60 dage).
- Ingen permanent sletningslog. Hvad den natlige kørsel har slettet, registreres ikke (afsnit 6).
- Intet uafhængigt andet kontrolpunkt. Sonden på en anden placering er ikke sat op (A.6).
9. Databeskyttelsesrådgiver – vurdering efter Art. 37 GDPR
Resultat: Efter vores vurdering er der ingen pligt til at udpege en databeskyttelsesrådgiver. Vurderingen indgår i den juridiske gennemgang og gentages, så snart en af de nedenfor anførte omstændigheder ændrer sig.
Art. 37(1) kræver udpegelse i tre tilfælde.
- Litra (a) (offentlig myndighed eller offentligt organ) finder ikke anvendelse.
- Litra (b) (kerneaktiviteter, der kræver regelmæssig og systematisk overvågning af registrerede i stort omfang): vores kerneaktivitet er regelmæssig, systematisk kontrol af websteder og formularer, ikke observation af personer. Vi opretter ingen profiler af besøgende, bruger ingen sporing og forbinder ingen besked med en anden. Leveringskontrollen (A.1) leder rigtige besøgendes beskeder gennem vores postkasse, men evaluerer kun headere og de første 8 KB med henblik på tildeling og gemmer intet indhold; den observerer leveringsveje, ikke personer. Kundekonti og logge er accessoriske i forhold til forretningsaktiviteten.
- Litra (c) (behandling i stort omfang af særlige kategorier efter Art. 9 eller af oplysninger om strafbare forhold efter Art. 10 som kerneaktivitet): ikke opfyldt. Særlige kategorier kan forekomme tilfældigt i kopier af formular-e-mails (A.1), på sider bag et login (A.5) eller i indsat kode (A.7); tilfældig indsamling er ikke en kerneaktivitet.
Art. 37(4) giver mulighed for, at national ret tilføjer yderligere tilfælde. Vi får en advokat til at bekræfte, om polsk ret kræver, at vi udpeger en databeskyttelsesrådgiver.
Udløsere for en ny vurdering: aktivering af sværmbeskyttelse med IP-netværk; en funktion, der genkender besøgende på tværs af flere beskeder eller websteder; lagring af indhold fra leveringskontrollen; en Kunde, hvis formularer overvejende vedrører særlige kategorier (sundhed, jobansøgninger), med leveringskontrollen slået til i stort omfang; den første medarbejder med adgang til kundedata. En frivillig udpegelse er fortsat mulig; Art. 37 til 39 finder så fuldt ud anvendelse.
Særskilt: om der kræves en konsekvensanalyse vedrørende databeskyttelse efter Art. 35 for enkelte behandlingsaktiviteter, besvares på siden Konsekvensanalyse vedrørende databeskyttelse. Dens tærskelvurdering konkluderer, at en konsekvensanalyse er påkrævet for sværmbeskyttelse (B.21) og for undersøgelser i det tilsigtede omfang (B.7) og gennemføres af os, og at den for leveringskontrollen (A.1) er påkrævet i den typiske konstellation som en forpligtelse for Kunden, som vi støtter heri.
10. Åbne punkter og planlagte foranstaltninger
Følgende punkter er dokumenteret i koden, skemaet eller konfigurationen, ikke antaget. De beskriver situationen på datoen for denne version; klassificeringen er vores egen og foregriber ikke nogen juridisk vurdering. De er ordnet efter deres betydning for de registrerede, ikke efter hvor lette de er at afhjælpe. De planlagte foranstaltninger og deres prioritet er beskrevet i konsekvensanalysen vedrørende databeskyttelse.
| Åbent punkt | Hvad der er dokumenteret | Betydning |
| Mailtjenesteudbyder uden dokumenteret kontrakt | For Namecheap, Inc. (Private Email), Phoenix, Arizona, USA er kontrakten, behandlingsstederne og overførselsgrundlaget ikke dokumenteret. Konto-e-mails, alarmer og kontrolpostkassen med rigtige besøgendes beskeder går gennem denne udbyder. | De relevante bestemmelser er Art. 28(2) og (4) samt kapitel V i GDPR. Indgåelse og dokumentation er planlagt før lanceringen. |
| Grundlag for chattjenester og reCAPTCHA uafklaret | Alarmer til Telegram (ingen afgørelse om tilstrækkeligt beskyttelsesniveau), Slack, Discord, Microsoft Teams og Google Chat; reCAPTCHA uden anmodning om samtykke. | Åbne spørgsmål til den juridiske gennemgang; indtil da er oplysning og grundlag ikke endelige. |
| Kontrolpostkassen kan rumme beskeder under forstyrrelser | Sletningen sker efter vellykket behandling; hvis hentningen mislykkes, bevares kopierne indtil næste vellykkede kørsel. Der advares ikke, når der over længere tid ophobes et efterslæb i postkassen. | Kopierne indeholder rigtige henvendelser fra besøgende. |
| Ingen sikkerhedskopi på en anden placering, ingen kryptering af databasen i hvile | Afsnit 8.1. En krypteret kopi af sikkerhedskopien på en anden placering er planlagt. | En enkelt hændelse på placeringen ville ramme data og sikkerhedskopi på samme tid; et stjålet lagermedie ville kunne læses. |
| Uløste anomalier uden opbevaringsperiode | Anomalier med den fulde IP-adresse som nøgle slettes først 90 dage efter løsning; det, der aldrig løses, bevares. | Vedrører princippet om opbevaringsbegrænsning (Art. 5(1)(e)); sletningen afhænger af manuel løsning. En fast opbevaringsperiode er planlagt (foranstaltninger i konsekvensanalysen vedrørende databeskyttelse). |
| Fejltyper med eksempelmeddelelse uden opbevaringsperiode | Eksempelmeddelelsen gemmes uændret op til 2.000 tegn; det rensede mønster fjerner adresser og numre, eksemplet gør ikke. | Fejlmeddelelser kan indeholde e-mailadresser, værtsnavne eller IP-adresser. |
| Scriptoversigt uden egen opbevaringsperiode | Scriptoversigt og scriptændringer slettes sammen med domænet (FE_DOMAIN_TABELLEN), også når arbejdsområdet eller kontoen slettes, og i den natlige kørsel for forældreløse data; de har ingen egen opbevaringsperiode. De indeholder scriptadresser, sideadresser og, ved godkendelser, den godkendende person og en begrundelse i fritekst. | Vedrører princippet om opbevaringsbegrænsning (Art. 5(1)(e)); ændringsloggen med godkendelserne vokser, så længe domænet findes. |
| Abonnenter på tilbagekaldte portaler | En tilbagekaldt portal spærres, men slettes ikke; dens abonnenter bevares, indtil arbejdsområdet slettes. | Formålet (udsendelse af rapporten) bortfaldt med tilbagekaldelsen. |
| Undersøgelseslister uden opbevaringsperiode | Efter offentliggørelse bevares hosts og segmenter; undersøgelser, der aldrig offentliggøres, beholder også deres rådata. | Løftet »rådata slettes« gælder kun for offentliggjorte undersøgelser. |
| Interne kontroller uden sletningsrute | Kontroller med tillidsniveauet »intern«, som hverken har et domæne eller en rapport (undersøgelser og kontroller, som operatøren har oprettet fra kommandolinjen), er ikke omfattet af nogen sletningsrute; sammen med dem bevares formularer, fund og skærmbilleder af tredjeparters websteder. | Vedrører princippet om opbevaringsbegrænsning (Art. 5(1)(e)); berører personer, der intet ved om kontrollen. Vurderet som høj risiko i konsekvensanalysen vedrørende databeskyttelse. |
| Bevis for kontrol fornys ikke | Bevis for kontrol kontrolleres én gang; der findes ingen rute i koden, hvorved et domæne mister det igen. | Aktive testindsendelser, filsøgning og scanning bag login fortsætter efter et ejer- eller mandatskifte. |
| Scanning bag login: transport til Kundens side | Som loginadresse tillades http ved siden af https, og certifikatfejl på Kundens side stopper ikke login. | Adgangsoplysninger til testkonti kunne opsnappes på vej til Kundens side. |
| Sletning afhænger af et tidsvindue | Den daglige blok kører kun, hvis en statuskørsel starter mellem kl. 03.00 og 03.04. Hvis netop denne kørsel mislykkes (database utilgængelig, server genstartet), sker dagens sletning og sikkerhedskopi ikke; der foretages ingen indhentning. Hvad der blev slettet, logges ikke permanent. | Opbevaringsperioderne forlænges så stiltiende med en dag. Et mistet tidsvindue udløser ingen alarm; kun en sikkerhedskopi, der kører og mislykkes, rapporteres. Opsætningslisten i administrationsområdet viser datoen for den seneste vellykkede sikkerhedskopi. |
| Visse sletninger afhænger af overvågningen | Tømning af leveringskontrollens kontrolpostkasse, sletning af hændelser, sendte samlede meddelelser, sværmsignaler og kontroller af potentielle kunder samt rydning af resterende kopier af testkonti i job kører i planlægningsdelen af statuskørslen, som kun arbejder, mens overvågningen er slået til i administrationsområdet; tildelingerne i leveringskontrollen slettes kun, mens en kontrolpostkasse er sat op. | Hvis overvågningen slås fra centralt, eller postkassen fjernes, standser disse opbevaringsperioder, uden at nogen bemærker det. |
| Rapporteringssted og postkasser uden opbevaringsperiode | Sårbarhedsrapporter og andre indgående e-mails opbevares uden for applikationen; der er ikke fastsat nogen opbevaringsperiode. | Rapporter kan indeholde bevismateriale om tredjeparter. |
| Værdier i skjulte felter læses under kontrollen | Scanneren læser værdien af skjulte formularfelter op til 24 tegn og dataattributter op til 60 tegn for at genkende tidsstempler og tokens. Kun feltnavn, type, etiket og genkendelsesresultatet indgår i feltoversigten og fundene, ikke værdien. | Intet hul i lagringen; værdien findes kun i scancontainerens arbejdshukommelse under kontrollen. En forudfyldt værdi (f.eks. et kundenummer) læses i den forbindelse, men gemmes ikke. |
| Afledt afsenderdomæne i autentificeringsresultatet | A.1. | For besøgendes personlige domæner er det personoplysninger, der stammer fra en rigtig besked. |
| Hærdningen af serveradministrationen er ikke afsluttet; interne forbindelser er ikke gennemgående krypteret | Afsnit 8.1. Hærdningen fortsætter; vi oplyser ikke detaljer offentligt. | En sikkerhedshændelse på serverniveau ville ramme applikation, database og sikkerhedskopier på samme tid. |
| Måling på udviklingssystemet | Skema, kode og indstillinger blev målt på udviklingssystemet. | Kode og skema svarer til produktionssystemet; indstillinger kan afvige og skal kontrolleres igen dér før lanceringen. |
11. Vedligeholdelse af denne fortegnelse
Art. 30 kræver, at fortegnelsen føres skriftligt og stilles til rådighed for tilsynsmyndigheden efter anmodning. Det kræver en person, der er ansvarlig for den, og et interval, hvor den kontrolleres op mod systemet og ikke op mod sin tidligere version.
- Ansvar: Lukas Wójcik, indehaver. Den gennemgås årligt og hver gang en behandlingsaktivitet ændres.
- Hændelser, der kræver en opdatering: en ny eller ændret underdatabehandler, især valget af mailtjenesteudbyder; en ny tabel eller et nyt felt med personoplysninger; en ændring af opbevaringsperioderne eller sletningskæderne i
cfg/fristen_lib.php eller srv/cron_status.php; en ny alarmkanal eller en ny forespørgsel til en tredjepart; aktivering af en funktion, der er slået fra som standard (sværmbeskyttelse med IP-netværk, sonde, egne domæner, partnerprogram, betaling via faktura, Spamhaus eller Google Web Risk); en flytning til andre servere.
- Fremgangsmåde: hvert udsagn her stammer fra kode, skema eller måling. En gennemgang, der kun læser teksten, har ikke gennemgået noget: skema og sletningskæder måles igen, pladsholdere forbliver pladsholdere, åbne punkter lukkes eller videreføres med begrundelse.
- Forhold til andre dokumenter: denne fortegnelse erstatter ikke privatlivspolitikken, databehandleraftalen, de tekniske og organisatoriske foranstaltninger eller listen over underdatabehandlere. Hvor de og denne fortegnelse afviger fra hinanden, er afvigelsen et fund.
- Ændringer af dette dokument er anført på siden Ændringer af kontraktdokumenterne.