Konsekvensanalyse vedrørende databeskyttelse (Art. 35 GDPR)

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

Version 1.0 · Senest opdateret: 16. oktober 2026

1. Hvad det drejer sig om, og hvad denne side er

Denne side er konsekvensanalysen vedrørende databeskyttelse (DPIA) for formexposed efter Art. 35 GDPR. Først besvarer den det indledende spørgsmål, om en konsekvensanalyse overhovedet er påkrævet – for hver behandlingsaktivitet for sig, ikke for tjenesten som helhed. Hvor svaret er ja, gennemfører den vurderingen efter Art. 35(7)(a) til (d): en systematisk beskrivelse, nødvendighed og proportionalitet, risiciene for de registrerede og foranstaltningerne til imødegåelse af dem. Derefter følger restrisikoen, spørgsmålet om forudgående høring efter Art. 36 og reglerne for revision.

Art. 35 kræver ikke, at en konsekvensanalyse offentliggøres. Vi offentliggør den af to grunde. For det første har Kunder, der bruger leveringskontrollen eller scanningen bag login, brug for fakta til deres egen vurdering, som kun vi kender; dem skylder vi dem under alle omstændigheder som databehandler (Art. 28(3)(f) GDPR). For det andet kontrollerer vores crawler websteder, hvis operatører ikke kender os. De skal kunne læse, hvilke risici vi ser for dem og for personerne på deres sider, og hvad vi gør ved dem.

Retlig karakter. Denne konsekvensanalyse er den dataansvarliges dokumentation efter Art. 35 GDPR, som vi offentliggør frivilligt. Den er ikke en del af nogen kontrakt og udgør ingen erklæring, garanti eller aftale om beskaffenhed over for Kunder eller tredjeparter. Hvilke ydelser og garantier vi skylder Kunderne, er reguleret af Servicevilkårene, Databehandleraftalen og dens bilag; med hensyn til disse forpligtelser har de forrang for denne side. Siden beskriver situationen på datoen for denne version. Risikovurderinger og bedømmelser er vores egen opfattelse og foregriber ikke nogen juridisk vurdering foretaget af en tilsynsmyndighed eller en domstol; foranstaltninger, der er beskrevet som »planlagt«, er hensigter uden en bindende dato. For Kunderne er siden et grundlag for deres egen vurdering, ikke juridisk rådgivning.

Dette er den første version af tærskelvurderingen. Den undersøger behandlingsaktivitet for behandlingsaktivitet, om en konsekvensanalyse er påkrævet, og registrerer resultatet i afsnit 3.5.

Ethvert faktuelt udsagn er underlagt samme princip som i vores øvrige juridiske dokumenter: målt, ikke tilsigtet. Det, der er dokumenteret i koden eller i databasen, anføres her med kildehenvisning. Det, der ikke kunne dokumenteres, er markeret »ikke verificeret«. Det, der blot er planlagt, kaldes »planlagt«. Vi nævner åbne punkter åbent sammen med den planlagte foranstaltning; en konsekvensanalyse, der kun oplister styrker, hjælper ikke de personer, den vedrører.

Begreber: en operatør er den, der driver et kontrolleret websted. En Kunde har en konto hos formexposed. En besøgende er den, der bruger en Kundes websted, f.eks. dets kontaktformular. En kildehenvisning betegner en fil, en funktion eller en indstilling i kildekoden, målt i forhold til udviklingssystemets tilstand den 11. oktober 2026.

Vi trækker bevidst én grænse for åbenheden: åbne punkter i sikringen af vores egne servere beskrives kun i generelle vendinger (R13). Vi nævner risikoen og dens niveau, men ikke vejen til en konkret sårbarhed; detaljerne stiller vi til rådighed for en tilsynsmyndighed efter anmodning.

2. Roller: hvem bærer forpligtelsen, og for hvad

Art. 35 pålægger den dataansvarlige forpligtelsen. formexposed er dataansvarlig for nogle behandlingsaktiviteter, databehandler for sine Kunder for andre og ingen af delene for de data, som vores WordPress-plugin og vores TYPO3-udvidelse gemmer på en Kundes websted. Svaret på næsten ethvert spørgsmål i dette dokument afhænger af, hvilken rolle spørgsmålet stilles om. Fordelingen følger Privatlivspolitikken og Databehandleraftalen.

Behandlingsaktivitet	formexposeds rolle	Hvem bærer forpligtelsen efter Art. 35
Kontrol af tredjeparters websteder uden instruks fra deres operatør: gratis kontrol, kontrol af potentielle kunder for bureauer, undersøgelse	Dataansvarlig	formexposed
Kontrol af domæner i Kundekontoen: overvågning, aktive testindsendelser, browserforløb, eksponerede filer, formularpuls	Dataansvarlig for Kundens konto- og kontroldata; databehandler for tredjeparters personoplysninger, der er synlige på Kundens verificerede websted; så længe et domæne ikke er verificeret, dataansvarlig som ved den gratis kontrol	formexposed for sin egen del; Kunden for tredjepartsdata på sit websted
Scanning bag login med en testkonto	Databehandler: adgangsoplysningerne og indholdet bag login tilhører Kundens websted	Kunden; formexposed bistår
Leveringskontrol med kontrolkopi	Databehandler	Kunden; formexposed bistår
Sværmbeskyttelse: fælles liste over linkdomæner fra blokeret spam	Dataansvarlig: vi samler rapporterne fra mange websteder, sammenstiller listen og distribuerer den	formexposed
Kundekonti, login, logge, support, afsendelse af e-mail, betalinger, bevisdokumenter	Dataansvarlig	formexposed
Kundeportal og månedsrapport til et bureaus abonnenter	Databehandler	Bureauet
Data, som pluginet og udvidelsen gemmer på Kundens websted (karantæne, sikkerhedsnet, gemte henvendelser)	Ingen af delene: dataene forlader aldrig webstedet	Den, der driver webstedet

Dette fører til en sondring, som vi udtrykkeligt fremhæver, fordi den ofte tages forkert i begge retninger. Hvor formexposed er dataansvarlig, gennemfører vi selv vurderingen og bærer dens resultat. Hvor vi er databehandler, kan vi ikke gennemføre Kundens vurdering i dennes sted, afgøre spørgsmålet om nødvendighed for den eller høre tilsynsmyndigheden efter Art. 36 på dens vegne. Det, vi kan og skal gøre dér, er at give den alt, hvad den har brug for: beskrivelsen efter litra (a), de målte fakta om risiciene efter litra (c) og en ærlig statusliste over foranstaltningerne efter litra (d). For leveringskontrollen og scanningen bag login er denne side netop det.

En Kunde, der uændret overtager afsnittene om leveringskontrollen som sin egen konsekvensanalyse, har ikke gennemført en. Om kontrolkopien er berettiget for dens formularer, om der må forventes særlige kategorier af personoplysninger dér, og hvordan den informerer sine besøgende, kan kun den selv afgøre. Afsnit 11 opsummerer, hvad der skal afklares med henblik herpå.

3. Tærskelvurdering: er en konsekvensanalyse påkrævet?

3.1 Art. 35(1) og Art. 35(3)

Art. 35(1) kræver en konsekvensanalyse, hvis en type behandling, navnlig ved brug af nye teknologier og under hensyntagen til behandlingens karakter, omfang, sammenhæng og formål, sandsynligvis vil indebære en høj risiko for fysiske personers rettigheder og frihedsrettigheder. Art. 35(3) nævner tre tilfælde, hvor dette navnlig er tilfældet. Ingen af de tre passer på formexposed, og det bør begrundes frem for blot at blive påstået:

• Litra (a) – en systematisk og omfattende vurdering af personlige forhold vedrørende fysiske personer, som er baseret på automatisk behandling, og som er grundlag for afgørelser, der har retsvirkning eller på tilsvarende vis betydeligt påvirker dem. Vi vurderer formularer og websteder, ikke personlige forhold vedrørende mennesker. Tjenesten træffer ingen afgørelse med retsvirkning for nogen person. Det, der kommer tættest på, er sværmbeskyttelsen: beskeder, der indeholder et link til et listet domæne, havner i karantæne på de forbundne websteder. Det er en automatisk konsekvens for beskeden, ikke en omfattende vurdering af en person; vi behandler det under kriteriet »Evaluering eller scoring« i afsnit 3.3.
• Litra (b) – behandling i stort omfang af særlige kategorier efter Art. 9 eller af oplysninger om strafbare forhold efter Art. 10. Ikke tilsigtet og ikke bygget. Sådanne data kan alligevel nå os ad én vej: i kontrolkopien af rigtige besøgendes beskeder i leveringskontrollen. Det afhænger af det enkelte tilfælde og er ikke i stort omfang i denne bestemmelses forstand; det indgår dog i risikovurderingen (R1).
• Litra (c) – systematisk overvågning af et offentligt tilgængeligt område i stort omfang. Herved forstås fysisk observation af steder, ikke hentning af offentlige websider. Det ville være forkert at bruge denne bestemmelse som knage for en webcrawler.

Den korrekte vej er derfor selve Art. 35(1), anvendt via de ni kriterier i Artikel 29-Gruppens retningslinjer om konsekvensanalyse vedrørende databeskyttelse (WP248 rev.01, godkendt af Det Europæiske Databeskyttelsesråd), og den polske tilsynsmyndigheds liste efter Art. 35(4) (afsnit 3.4).

3.2 De ni kriterier i WP248-retningslinjerne

Retningslinjerne nævner ni kendetegn, der peger på en sandsynlig høj risiko. Som tommelfingerregel vil en behandlingsaktivitet, der opfylder to af dem, i de fleste tilfælde kræve en konsekvensanalyse. En dataansvarlig kan i et konkret tilfælde nå til en anden konklusion, men skal så begrunde og dokumentere den. Omvendt kan et enkelt kriterium være nok. På denne side bruger vi følgende korte betegnelser:

1. C1 – Evaluering eller scoring, herunder profilering og forudsigelse, f.eks. af arbejdsindsats, økonomisk situation, pålidelighed eller adfærd.
2. C2 – Automatiske afgørelser med retsvirkning eller tilsvarende betydelig virkning.
3. C3 – Systematisk overvågning, dvs. behandling, der bruges til at observere, overvåge eller kontrollere registrerede, herunder via netværk. Retningslinjerne begrunder udtrykkeligt dette kriterium med, at de registrerede ofte ikke ved, hvem der indsamler deres data og til hvilket formål.
4. C4 – Følsomme data eller data af meget personlig karakter: særlige kategorier efter Art. 9 og 10, men også data, hvis videregivelse påvirker dagligdagen betydeligt, herunder elektronisk kommunikation, hvis fortrolighed bør beskyttes.
5. C5 – Data, der behandles i stort omfang, målt på antallet af registrerede, mængden og bredden af data, varigheden og den geografiske udstrækning.
6. C6 – Matchning eller sammenkobling af datasæt, der stammer fra forskellige behandlingsaktiviteter eller fra forskellige dataansvarlige, på en måde, som de registrerede ikke ville forvente.
7. C7 – Data vedrørende sårbare registrerede, f.eks. ansatte, børn, patienter eller andre personer i et ulige magtforhold.
8. C8 – Innovativ anvendelse eller anvendelse af nye teknologiske eller organisatoriske løsninger; i tilsynspraksis behandles brugen af kunstig intelligens regelmæssigt som omfattet af dette kriterium.
9. C9 – Behandling, der forhindrer de registrerede i at udøve en rettighed eller benytte en tjeneste eller en kontrakt.

Vi bedømmer hvert kriterium som »opfyldt«, »grænsetilfælde« eller »ikke opfyldt« og begrunder bedømmelsen ud fra koden. Et grænsetilfælde tæller ikke som opfyldt i summen, men nævnes i resultatet; hvor flere grænsetilfælde peger i samme retning, inddrager vi behandlingsaktiviteten i vurderingen.

3.3 Vurdering pr. behandlingsaktivitet

P1 – Gratis kontrol uden konto (kontrol af et vilkårligt tredjepartswebsted efter anmodning)

Enhver kan indtaste et domæne på forsiden. Crawleren henter derefter højst otte offentlige sider fra dette websted, læser formularerne, tager skærmbilleder og udarbejder en rapport, som alle, der kender dens tilfældige link, kan se. Den, der driver webstedet, får intet at vide om det, medmindre vedkommende bemærker crawlerens identifikator i sine logge.

• C1 – grænsetilfælde. Rapporten bedømmer beskyttelsen af en formular med et niveau (»Eksponeret«, »Delvist beskyttet«, »Beskyttet«) og en score. For et anpartsselskab vedrører dette ikke en fysisk person. For enkeltmandsvirksomheder og freelancere kan domænet henføres til personen, og niveauet siger så noget om den omhu, der udvises i vedkommendes erhvervsaktivitet. Det, der vurderes, er dog en teknisk opsætning, ikke en persons adfærd eller egenskaber. Vi behandler dette som et grænsetilfælde.
• C2 – ikke opfyldt. Der træffes intet i forhold til operatøren. I forhold til den person, der anmoder om kontrollen, gælder grænser pr. IP-adresse og session (cfg/check_lib.php); en afvist kontrol har ingen betydelig virkning.
• C3 – ikke opfyldt. Det er en enkelt hentning efter anmodning, højst én gang pr. domæne og uge (cfg/check_lib.php, indstillingen fc_domain_days = 7). Ingen personer observeres. Den omstændighed, som retningslinjerne anfører som begrundelse for C3 – de registrerede ved intet om behandlingen – foreligger dog. Den indgår i risikovurderingen (R5).
• C4 – ikke opfyldt. Det, der gemmes, er formularstrukturen og fund, ikke indtastede værdier (scanner/src/crawl.js gemmer kun længden af en værdi for synlige felter). Scanneren læser begyndelsen af forudfyldte skjulte felter (op til 24 tegn) og dataattributter (op til 60 tegn) kun under kontrollen for at genkende tokens og tidsstempler; de gemmes ikke. Skærmbilleder kan tilfældigt vise personer og navne; en lægepraksis' websted viser dens speciale på billedet. Det er offentlige faglige oplysninger, ikke helbredsoplysninger om en bestemt person.
• C5 – grænsetilfælde. Dagsloftet er 200 accepterede kontroller (fc_daily_cap), dvs. regnemæssigt op til omkring 73.000 websteder om året. Der opstår kun få personoplysninger pr. websted, og varigheden er kort (30 dage). Målt på udviklingssystemet er der 2 anonyme kontroller i datasættet. Ikke opfyldt i dag; et grænsetilfælde i betragtning af den dimensionerede kapacitet.
• C6 – ikke opfyldt. Ud over at hente siderne forespørger tjenesten domænets alder via RDAP-tjenesten rdap.org (kun domænenavnet overføres; kun registreringsdatoen gemmes, cachet) og opslår DNS. Det er tekniske oplysninger om domænet, ikke en sammenkobling af datasæt om personer.
• C7 – ikke opfyldt.
• C8 – opfyldt i svag form. En automatiseret browser kontrollerer siderne, og en sprogmodel på vores egen server klassificerer formularer, som reglerne ikke genkender (scanner/src/classify.js). Modellen ser sidetitlen, adressen, feltetiketterne og op til 400 tegn formulartekst. Den kan aldrig gøre en formular »indsendbar«.
• C9 – ikke opfyldt.

Foreløbigt resultat P1: ét kriterium i svag form (C8), to grænsetilfælde (C1, C5). Ingen forpligtelse efter tommelfingerreglen. Fordi begge grænsetilfælde peger i samme retning, og de registrerede intet ved om behandlingen, inddrager vi P1 i vurderingen.

P2 – Kontrol af potentielle kunder for bureauer

Et bureau på Business-planen med eget brand sat op kan få en potentiel kundes websted kontrolleret passivt. Det modtager et kort resultat under sit brand og en detaljeret rapport og giver selv linket videre (cfg/akquise_lib.php). Vi kontakter ingen.

• C1 – grænsetilfælde, stærkere end for P1. Det korte resultat er udtrykkeligt tænkt som en »døråbner til den første samtale«. Vurderingen af webstedet bliver dermed grundlaget for at henvende sig kommercielt til en person.
• C5 – ikke opfyldt. Højst 30 kontroller pr. bureau og måned (prospect_monthly), slettet efter 90 dage.
• C8 – opfyldt i svag form (samme teknologi som P1).
• Øvrige kriterier – ikke opfyldt. Resultatet præsenteres med bureauets brand, men kobles ikke med andre data om operatøren.

Foreløbigt resultat P2: ingen forpligtelse efter tommelfingerreglen; inddraget af samme grunde som P1 og fordi formålet – kundeerhvervelse – indebærer en selvstændig risiko (R6).

P3 – Undersøgelsen »Form Security Index«

Til en undersøgelse kontrolleres en liste over websteder passivt, begrænset til højst fem åbne job pr. kørsel af statusprocessen, som kører hvert femte minut (cfg/studie_lib.php). Kun samlede tal offentliggøres, og segmenter først fra 20 websteder med en formular (study_min_segment, cfg/studie_lib.php). Rådataene slettes ved offentliggørelsen (cfg/studie_lib.php).

• C5 – grænsetilfælde, opfyldt for store lister. Listens størrelse er ikke begrænset i koden; begrænsningen tillader regnemæssigt mere end tusind kontroller om dagen. En undersøgelse af et nationalt marked omfatter tusindvis af websteder, mange af dem drevet af enkeltmandsvirksomheder. Fra en sådan størrelse betragter vi kriteriet som opfyldt.
• C8 – opfyldt i svag form.
• C1 – ikke opfyldt. Selv om det enkelte websted bedømmes, offentliggøres kun summen; bedømmelsen tjener ikke til at udtale sig om den enkelte operatør.
• Øvrige kriterier – ikke opfyldt.

Foreløbigt resultat P3: for undersøgelser af den dimensionerede størrelse to kriterier (C5, C8). Undersøgelsen når derfor tærsklen; formexposed gennemfører vurderingen som dataansvarlig. Målt på udviklingssystemet er der endnu ikke oprettet nogen undersøgelse.

P4 – Kontrol af domæner i Kundekontoen

Kunden får domænerne i sin konto kontrolleret regelmæssigt. Når den har bevist, at den har ret til at kontrollere domænet, kommer aktive testindsendelser (højst fem pr. kontrol), søgningen efter eksponerede filer og konfigurerede browserforløb til.

• C3 – ikke opfyldt. Kontrollen er planlagt og tilbagevendende, men den vedrører Kundens eget websted og foretages på dennes anmodning, ikke for at observere personer.
• C4 – grænsetilfælde, nej. Søgningen efter eksponerede filer læser højst de første 8 KB fra stier som /backup.sql eller en fejlfindingslog for ud fra indholdet at afgøre, om filen virkelig er eksponeret (cfg/dateien_lib.php). Et sådant uddrag kan indeholde formularindtastninger foretaget af besøgende. Det kontrolleres kun i hukommelsen og gemmes aldrig; det, der gemmes, er sti, type og alvorlighed.
• C8 – opfyldt i svag form.
• Øvrige kriterier – ikke opfyldt.

Foreløbigt resultat P4: ingen forpligtelse. Inddraget, fordi de aktive testindsendelser og filkontrollen afhænger af et bevis, der aldrig fornys (R7).

P5 – Scanning bag login

For et verificeret domæne kan Kunden gemme en testkonto til sit websted. Scanneren logger ind med den og læser formularerne på op til fem angivne sider i medlemsområdet (cfg/login_lib.php, scanner/src/login.js).

• C4 – grænsetilfælde. Adgangsoplysninger er ikke data af meget personlig karakter i retningslinjernes forstand, men misbrug af dem åbner medlemsområdet. Afhængigt af webstedet kan der ligge fortroligt indhold bag et login, f.eks. i en medlems- eller patientportal. Det afhænger af Kunden, ikke af os.
• C8 – ikke opfyldt. Automatiserede login er almindelige i overvågningstjenester.
• Øvrige kriterier – ikke opfyldt.

Foreløbigt resultat P5: ingen forpligtelse efter tommelfingerreglen. For Kunder, hvis medlemsområde viser fortroligt indhold, kan dette ændre sig; afgørelsen ligger så hos dem. Inddraget på grund af sikkerhedsrisiciene (R8).

P6 – Leveringskontrol med kontrolkopi

Kunden indtaster en kontroladresse hos formexposed som bcc i mailindstillingerne for sin formular. Som følge heraf går enhver formular-e-mail også til vores kontrolpostkasse – vores testbesked såvel som enhver rigtig besked fra en besøgende. En automatisk hentning læser headerne og de første 8 KB, tildeler e-mailen, evaluerer SPF, DKIM og DMARC og sletter den (cfg/zustellung_lib.php).

• C4 – opfyldt. Det, som besøgende skriver i en kontaktformular, er elektronisk kommunikation til en virksomhed med vilkårligt indhold. På webstedet for en lægepraksis, et advokatfirma, en rådgivningstjeneste eller en skole må der forventes data efter Art. 9 eller om børn. Retningslinjerne nævner udtrykkeligt fortrolig elektronisk kommunikation under dette kriterium.
• C3 – grænsetilfælde, snarere opfyldt. Hver besked kopieres planmæssigt og løbende og evalueres automatisk, uden at afsenderen bemærker det. Formålet er at kontrollere mailruten, ikke at observere personer. Den omstændighed, som retningslinjerne begrunder kriteriet med – de registrerede ved ikke, hvem der modtager deres data – foreligger dog fuldt ud, så længe Kunden ikke informerer sine besøgende.
• C7 – afhænger af Kunden. Patienter, klienter hos advokatfirmaer, jobansøgere, forældre og elever står ofte i et afhængighedsforhold til modtageren af deres besked.
• C5 – grænsetilfælde, nej. Ikke i stort omfang for den enkelte Kunde. Hos formexposed samles mange Kunders kopier i én postkasse; det øger vægten af et brud, ikke antallet pr. dataansvarlig.
• Øvrige kriterier – ikke opfyldt. Tildelingen til domæne og test er ikke en matchning af datasæt om personer; teknologien er ikke ny.

Foreløbigt resultat P6: C4 opfyldt, C3 grænsetilfælde og snarere opfyldt, C7 opfyldt for mange typiske Kunder. I den typiske konstellation er to eller flere kriterier derfor opfyldt. En konsekvensanalyse er påkrævet – som en forpligtelse for Kunden, der er dataansvarlig. Afsnit 6 til 11 giver Kunden fakta hertil.

P7 – Sværmbeskyttelse

Forbundne WordPress-websteder rapporterer én gang om dagen domænerne for links fra beskeder, som deres beskyttelseslag har stoppet. Et domæne, der optræder på mindst tre forskellige websteder med mindst fem hits inden for syv dage, kommer på en fælles liste; listen sendes tilbage til alle forbundne websteder, som derefter flytter beskeder med links til dette domæne i karantæne (cfg/swarm_lib.php).

• C6 – opfyldt. Rapporter fra mange indbyrdes uafhængige websteder, dvs. fra forskellige dataansvarlige, sammenkobles og returneres til dem alle som en fælles liste.
• C1 – opfyldt, for så vidt et domæne kan henføres til en fysisk person. Listen er en klassificering som spamkilde. Retningslinjerne nævner screening mod en fælles svindeldatabase som eksempel på dette kriterium. De fleste domæner på en sådan liste tilhører virksomheder eller er engangsdomæner; en privatpersons domæne kan dog havne på den, med rette eller gennem bevidst plantede falske rapporter.
• C9 – grænsetilfælde. En besked med et listet link når ikke straks frem til modtageren, men ligger i dennes karantæne, indtil den frigives. Den går ikke tabt.
• C2 – ikke opfyldt. Karantænen er en automatisk konsekvens for en besked, uden retsvirkning og med menneskelig frigivelse hos modtageren.
• Øvrige kriterier – ikke opfyldt. IP-netværk er slået fra (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Foreløbigt resultat P7: to kriterier (C6, C1) og ét grænsetilfælde (C9). Tærsklen er nået; formexposed gennemfører vurderingen som dataansvarlig. Med IP-netværk slået til ville C1 og C6 være opfyldt uden forbehold; aktivering kræver en ny version af denne vurdering (afsnit 12). Målt på udviklingssystemet er der hverken rapporter eller listeposter.

P8 – Kundekonti, login, logge, support, e-mail, betalinger

• C1 og C9 – ikke opfyldt. Påfaldende adfærd i den gratis kontrol fører til en note med IP-adressen (cfg/check_lib.php) og i givet fald til, at yderligere kontroller afvises. Det er forebyggelse af misbrug med ringe virkning, ikke en vurdering af personlige forhold.
• Øvrige kriterier – ikke opfyldt. Det er de sædvanlige data for en tjeneste til virksomheder.

Foreløbigt resultat P8: ingen konsekvensanalyse påkrævet. Behandlingsaktiviteterne er beskrevet i Fortegnelsen over behandlingsaktiviteter.

P9 – Plugin-tal, feltfejl, optager, badge, kundeportal, »Fix it for me«

• Pluginet og udvidelsen overfører dagstal, plugin-oversigten og fejlkategorier, og WordPress-pluginet overfører desuden linkdomæner til sværmbeskyttelsen (slået til som standard) (P7), intet indhold, ingen adresser, navne eller besøgendes IP-adresser; optageren opbevarer selektorer i højst 15 minutter i administratorens browser. Ingen kriterier opfyldt.
• Når badget indlæses, overføres de sædvanlige forbindelsesdata til webserverens log, uden cookie. Ingen kriterier opfyldt.
• Kundeportalen behandler abonnenters e-mailadresser med dobbelt opt-in på bureauets vegne. Ingen kriterier opfyldt.
• »Fix it for me« lader indsat formularkode omskrive af en sprogmodel på vores egen server; koden gemmes ikke. C8 i svag form, ellers intet.

Foreløbigt resultat P9: ingen konsekvensanalyse påkrævet.

3.4 Den polske tilsynsmyndigheds liste efter Art. 35(4)

Den kompetente myndighed er formanden for Kontoret for Beskyttelse af Personoplysninger (Prezes Urzędu Ochrony Danych Osobowych, UODO). Formanden offentliggjorde listen over de typer behandlingsaktiviteter, der kræver en konsekvensanalyse, i meddelelsen af 17. juni 2019 (Komunikat Prezesa Urzędu Ochrony Danych Osobowych z dnia 17 czerwca 2019 r. w sprawie wykazu rodzajów operacji przetwarzania danych osobowych wymagających oceny skutków przetwarzania dla ich ochrony, Monitor Polski 2019, pos. 666). Listen knytter sine punkter til kriterierne i WP248-retningslinjerne, giver eksempler og er udtrykkeligt ikke udtømmende; den erstatter ikke vurderingen efter Art. 35(1).

Efter vores læsning svarer følgende typer behandling på listen indholdsmæssigt til behandlingsaktiviteter hos formexposed:

Type behandling ifølge listen (gengivet med egne ord)	Tilknyttet kriterium	Behandlingsaktivitet hos formexposed	Vurdering
Sammenligning, evaluering eller udledning på grundlag af analyse af data fra forskellige kilder	C6	P7 Sværmbeskyttelse	finder anvendelse
Evaluering eller scoring, herunder profilering	C1	P7 Sværmbeskyttelse; P1 og P2 som grænsetilfælde	finder anvendelse på P7
Behandling af særlige kategorier af personoplysninger	C4	P6 Leveringskontrol	finder anvendelse afhængigt af Kunden
Innovativ anvendelse eller anvendelse af teknologiske løsninger	C8	P1 til P4 (sprogmodel til klassificering)	finder anvendelse i svag form
Behandling i stort omfang	C5	P3 Undersøgelse	finder anvendelse på store lister
Systematisk overvågning af offentligt tilgængelige steder, herunder med genkendelse af kendetegn	C3	–	finder ikke anvendelse: der menes steder, ikke websteder

Denne tilknytning er en læsning, ikke et citat; ordlyden af punkterne skal holdes op mod den i den juridiske gennemgang. Den bekræfter resultatet i afsnit 3.3, men ændrer det ikke. Så vidt vi ved, har UODO ikke offentliggjort en liste efter Art. 35(5) – behandlingsaktiviteter, for hvilke der ikke kræves en konsekvensanalyse.

3.5 Resultat af tærskelvurderingen

Behandlingsaktivitet	Opfyldt	Grænsetilfælde	Resultat
P1 Gratis kontrol	C8 (svag)	C1, C5	ikke obligatorisk; inddraget
P2 Kontrol af potentielle kunder	C8 (svag)	C1	ikke obligatorisk; inddraget
P3 Undersøgelse	C8 (svag), C5 for store lister	–	påkrævet (forpligtelse for formexposed)
P4 Kontrol af Kundedomæner	C8 (svag)	C4 (filkontrol)	ikke obligatorisk; inddraget
P5 Scanning bag login	–	C4	ikke obligatorisk; inddraget; for Kunden afhængigt af indholdet
P6 Leveringskontrol	C4; C7 afhængigt af Kunden	C3 (snarere opfyldt), C5	påkrævet (forpligtelse for Kunden; denne side bistår efter Art. 28(3)(f))
P7 Sværmbeskyttelse	C6, C1	C9	påkrævet (forpligtelse for formexposed)
P8 Konti, logge, support, betalinger	–	–	ikke påkrævet
P9 Plugin-tal, badge, portal, »Fix it for me«	C8 (svag, kun »Fix it for me«)	–	ikke påkrævet

Resultat vedrørende Art. 35(1): En konsekvensanalyse er påkrævet for enkelte behandlingsaktiviteter hos formexposed. Den er påkrævet for sværmbeskyttelsen og for undersøgelser af den dimensionerede størrelse, og formexposed gennemfører den som dataansvarlig. For leveringskontrollen er den påkrævet i den typiske konstellation, men som en forpligtelse for Kunden; formexposed leverer grundlaget. For de øvrige kontroller af tredjeparters og egne websteder er den ikke obligatorisk. Vi inddrager dem alligevel, fordi de bruger samme teknologi, fordi flere grænsetilfælde peger i samme retning, og fordi de registrerede – operatører uden konto og personer på kontrollerede sider – intet ved om behandlingen. For konti, logge, support og betalinger kræves ingen vurdering.

Afsnit 6 til 10 gælder derfor for P1 til P7. Hvor et udsagn kun gælder for én af disse behandlingsaktiviteter, er det markeret som sådan.

4. Databeskyttelsesrådgiver: vurderingen efter Art. 37

Der er ikke udpeget nogen databeskyttelsesrådgiver. Art. 37(1) forpligter både den dataansvarlige og databehandleren; spørgsmålet er derfor vores eget. De tre lovbestemte tilfælde:

Art. 37(1)	Betingelse	Resultat
litra (a)	Offentlig myndighed eller offentligt organ	Finder ikke anvendelse; LW IT Solutions Company Lukas Wójcik er en privat enkeltmandsvirksomhed.
litra (b)	Kerneaktiviteterne består af behandlingsaktiviteter, der kræver regelmæssig og systematisk overvågning af registrerede i stort omfang	Kerneaktiviteten er kontrol og overvågning af websteder og formularer, regelmæssigt og systematisk. Der overvåges dog ingen personer: crawleren observerer ikke adfærd, og leveringskontrollen evaluerer kun e-mails med henblik på levering og ægthed. Ikke opfyldt.
litra (c)	Kerneaktiviteterne består af behandling i stort omfang af data efter Art. 9 eller 10	Ikke ved design. Særlige kategorier kan nå os via leveringskontrollens kontrolkopi; det er tilfældigt, ikke en kerneaktivitet. Ikke opfyldt.

Efter vores vurdering er der derfor ingen pligt til at udpege en databeskyttelsesrådgiver. Om polsk ret kræver en udpegelse ud over dette efter Art. 37(4), er et åbent spørgsmål til den juridiske gennemgang. Da der ikke er udpeget nogen databeskyttelsesrådgiver, finder rådgivningen efter Art. 35(2) ikke anvendelse. Hvis den juridiske gennemgang fastslår, at der er pligt til at udpege en, indhentes rådgivning fra den så udpegede databeskyttelsesrådgiver, før denne vurdering godkendes (afsnit 12). Kontaktperson for spørgsmål om denne vurdering er indehaveren på contact@lukaswojcik.com.

5. Metode, kilder og begrænsninger ved denne version

Fakta i dette dokument stammer fra kildekoden til applikationen og scanneren, fra databaseskemaet samt fra rækkeantal og indstillinger på udviklingssystemet, målt den 11. oktober 2026. Der blev kun læst fra databasen og serverne. Hvor en måling modsiger en hensigt – herunder et udsagn i vores egne juridiske dokumenter – rapporterer vi målingen. Vi anvender ikke godkendte adfærdskodekser efter Art. 40, hvis overholdelse skulle tages i betragtning efter Art. 35(8).

• Det var udviklingssystemet, der blev målt. Tjenesten er endnu ikke lanceret. Tallene er derfor små og delvis artefakter fra test: 112 kontroller, heraf 110 uden Kundedomæne; 432 skærmbilleder; 2 domæner, heraf 1 verificeret; ingen leveringskontrol slået til; ingen testkonto gemt til scanningen bag login; ingen undersøgelse; ingen rapporter i sværmbeskyttelsen. Målingerne skal gentages før lanceringen og derefter med jævne mellemrum.
• Ikke målt i denne version og skal tilføjes før godkendelse er: konfigurationen af produktionssystemet, herunder om og hvordan kontrolpostkassen er sat op, og om nøgleparret til scanningen bag login er sat op dér; om sprogmodelsoftwaren logger forespørgsler; tilstanden af serveradministrationen (R13); kontrakten med e-mailtjenesteudbyderen.
• Det kunne ikke måles, hvor mange rigtige besøgendes beskeder der vil passere gennem kontrolkopien, og hvilke brancher Kunderne vil komme fra. Begge dele bestemmer vægten af R1 og R2 og skal fastslås efter lanceringen.
• Kildehenvisningerne peger på filer og funktioner i udviklingssystemets kildekode. Det afgørende er den beskrevne funktion, ikke dens placering i filen.

Dette dokument er et udkast. Det er endnu ikke godkendt af den dataansvarlige (afsnit 12), og to af dets konklusioner – vurderingen af omfanget for P1 og P3 og vægten af leveringskontrollen – afhænger af tal, der først vil foreligge efter lanceringen.

6. (a) Systematisk beskrivelse af behandlingsaktiviteterne og formålene

6.1 Hvordan kontrolsystemet er opbygget

formexposed kører på egne servere i Polen uden en ekstern hostingudbyder: en webserver med applikationen og databasen og en scanserver med kontroltjenesten og en lokal sprogmodel, begge i samme interne netværk. En kontrol forløber således:

1. Applikationen opretter et job i databasen – under forudsætning af de grænser og spærringer, der er beskrevet i afsnit 6.3.
2. Kontroltjenesten på scanserveren henter jobbet, kontrollerer spærrelisten, værtsnavne og, ved anonyme kontroller, domænets alder en gang til og starter en isoleret container til netop dette job: eget netværk med egne filterregler, ingen særlige rettigheder, skrivebeskyttet filsystem, hukommelses- og procesgrænser samt en tidsgrænse (scanner/src/worker.js).
3. I containeren henter en automatiseret browser højst otte offentlige sider, først forsiden, derefter fortrinsvis kontakt-, kolofon- og supportsider. Forinden læser den robots.txt; en udelukkelse for FormExposedBot eller for alle crawlere, der omfatter forsiden, afslutter kontrollen, og det samme gør en utilgængelig robots.txt eller en serverfejl ved hentningen (scanner/src/net.js). Forbud for enkelte understier overholdes ikke særskilt. Formularpuls, hentning af bevis, header-værktøjet og søgningen efter eksponerede filer læser ikke robots.txt. Ud over de otte sider kommer op til tre sider med et klik på »Afvis« i cookiebanneret, op til tre sider i mobilvisning, aktive prøver for verificerede domæner og op til fem sider bag et login; siderne indlæses efter hinanden, ikke parallelt. Hver forespørgsel fra browseren – herunder omdirigeringer og indlejret indhold – passerer et filter, der afviser private netværk og andre porte.
4. Containeren skriver et resultat og skærmbillederne til en midlertidig mappe. Kontroltjenesten overdrager resultatet og billederne til applikationen via det interne netværk og sletter den midlertidige mappe, også efter en fejl (scanner/src/worker.js).
5. Applikationen behandler resultatet, sammenligner det for Kundedomæner med den foregående kontrol og rapporterer ændringer til de mål, Kunden har sat op.

6.2 Hvad crawleren gemmer – og hvad den ikke gemmer

Element	Hvad der gemmes	Hvad der ikke gemmes	Kildehenvisning
Sider	Adresse, HTTP-status, headere, Content Security Policy, forespurgte tredjepartshosts (højst 120)	Sideindhold som tekst eller HTML	scanner/src/crawl.js
Formularfelter	Type, navn, etiket, pladsholder, obligatorisk felt, synlighed, længden af en eksisterende værdi	Feltværdier; for skjulte felter læses de første 24 tegn af værdien kun under kontrollen (for at genkende tokens)	scanner/src/crawl.js
Modtageradresser i formularen	kun domænet	adressen	scanner/src/crawl.js
Scripts	Oversigt med kontrolsum; adresser og indledende tekst uden kontoidentifikatorer for reklame- og analysetjenester	Konto- og pixelidentifikatorer	scanner/src/crawl.js
Medlæsere	hvilke reklamepixels og optageværktøjer der indlæses før og efter klik på »Afvis« i cookiebanneret, og om de maskerer input	Identifikatorer for kontiene hos disse tjenester	scanner/src/mitleser.js, scanner/src/einwilligung.js
Formulartekst	op til 400 tegn sendes til den lokale sprogmodel, hvis reglerne ikke genkender typen	Videregivelse til tredjeparter; lagring af teksten	scanner/src/classify.js
Skærmbilleder (crawler)	synligt område af den første side; for hver synlig formular et billede af formularelementet	–	scanner/src/crawl.js
Skærmbilleder (aktiv kontrol)	Billede af svarsiden på testindsendelsen; derudover status, måladresse, titel og de første 300 tegn af dens tekst	–	scanner/src/active.js
Skærmbilleder (browserforløb)	Billede af formularen med sværtede inputfelter, komprimeret, højst 32 KB	Input	scanner/src/browser.js
Bag login	som for formularfelter ovenfor	Skærmbilleder, cookies, links	scanner/src/login.js

Personoplysninger er ikke indeholdt i disse elementer ved design, men tilfældigt: navnet på en kontaktperson ved siden af formularen, et teamfoto på forsiden, et telefonnummer i en etiket, en privatpersons e-maildomæne, et navn i en pladsholder. Bag login kommer oplysninger om testkontoen og, afhængigt af webstedet, om andre brugere til.

6.3 Hvem udløser en kontrol, og hvad gælder der så

Udløser	Tillidsniveau i jobbet	Testindsendelser	Resultat tilgængeligt via	Sletning
Nogen indtaster et domæne på forsiden (gratis kontrol)	anonym	nej	Rapport under et tilfældigt link	30 dage, inklusive billeder (cfg/check_lib.php)
Plugin eller udvidelse uden konto	plugin	nej	Rapport under et tilfældigt link	30 dage
Bureau for en potentiel kunde	registreret	nej	Kort resultat og rapport under et tilfældigt link	90 dage (cfg/akquise_lib.php)
Kunde, domæne uden bevis	registreret	nej	Konto; rapport under et tilfældigt link	13 måneder, den seneste kontrol bevares
Kunde, domæne med bevis	verificeret	ja, højst fem pr. kontrol	Konto; rapport under et tilfældigt link	13 måneder, den seneste kontrol bevares (cfg/fristen_lib.php)
Undersøgelse	intern	nej	kun samlede tal efter offentliggørelse	ved offentliggørelse; uden offentliggørelse ingen tidsbegrænsning (R4)
Intern kontrol fra kommandolinjen foretaget af udbyderen	intern; for vores egne test- og demodomæner også »verificeret«	nej; med niveauet »verificeret« ja (kun vores egne test- og demodomæner)	kun internt	ingen tidsbegrænsning (R4)

Foran den gratis kontrol ligger flere lag (cfg/check_lib.php): et nødstop; reCAPTCHA; samme domæne højst én gang på syv dage (derefter vises den eksisterende rapport); grænser pr. IP-adresse, pr. session (som hashværdi, aldrig selve sessionsidentifikatoren) og for hele tjenesten pr. dag; spærrelisten fra opt-out og robots.txt; kontrollen af, at domænet peger på offentlige adresser; og en spærring for meget nye eller ukendte domæner. Anomalier – mange forskellige domæner fra én IP-adresse, mange forespørgsler på kort tid – noteres med IP-adressen og udløser et signal uden indhold (cfg/check_lib.php).

6.4 Kontrol af domæner i Kundekontoen

Kunden beviser, at den har ret til at kontrollere et domæne: via DNS-post, metatag, fil eller via vores plugin (cfg/verify_lib.php). Først derefter behandles domænet som verificeret. Overvågningsplanlæggeren planlægger kun regelmæssige kontroller for aktive, overvågede og verificerede domæner (cfg/monitor_lib.php).

• Aktive testindsendelser er bundet til to porte: applikationen sætter kun den aktive tilstand for Kunder for verificerede domæner (for vores egne test- og demodomæner kan udbyderen oprette en kontrol med niveauet »verificeret« via et internt kommandolinjeværktøj), og kontroltjenesten kontrollerer tillidsniveauet og nødstoppet fc_active_enabled igen (scanner/src/worker.js). Der kan kun indsendes en formular, som reglerne med stor sikkerhed genkender som en generel kontaktformular, som ikke har obligatoriske felter til rigtige personoplysninger, og hvis domæne ikke ligner en offentlig myndighed, en uddannelsesinstitution, en klinik, en lægepraksis, politiet eller en domstol (scanner/src/classify.js). Sprogmodellen kan ikke gøre en formular indsendbar (scanner/src/classify.js). Der sendes højst fem indsendelser pr. kontrol (fc_active_max_posts), tydeligt markeret, med afsenderen dummy@formexposed.com, en adresse under .invalid til test af e-mailvalidering og en harmløs ekstra headerlinje til at opdage header-injection (scanner/src/active.js).
• Browserforløb kontrollerer konfigurerede formularforløb i en browser frem til lige før indsendelsen. Kun GET- og HEAD-forespørgsler er tilladt; alt andet afbrydes, ligesom adresser med ord for at logge ud, slette, købe eller betale (scanner/src/browser.js). Til kontrollen udfyldes obligatoriske felter med opdigtede værdier, som aldrig forlader browseren.
• Eksponerede filer søges ugentligt, kun for verificerede domæner, med højst én hentning pr. sti, højst 8 KB, og indholdet gemmes aldrig (cfg/dateien_lib.php).
• En uafhængig anden sonde er forberedt og som standard slået fra (browser_probe_enabled = 0). Hvis den slås til, vil den kun modtage domæne, adresse, selektor, trin og browservalg, aldrig adgangsoplysninger, skærmbilleder eller besøgsdata (cfg/formular_probe_lib.php).

6.5 Scanning bag login

Forudsætninger: funktionen er sat op, domænet er verificeret, og Kunden har en betalt plan og er ejer eller administrator af arbejdsområdet (cfg/login_lib.php); Kunden bekræfter, at kontoen er en testkonto med så få rettigheder som muligt (cfg/login_lib.php).

1. Brugernavn og adgangskode krypteres straks på webserveren med scanserverens offentlige nøgle: en engangsnøgle pr. post (X25519), nøgleafledning (HKDF-SHA256), AES-256-GCM, bundet til domænet (cfg/login_lib.php). Kun kontroltjenesten på scanserveren har den private nøgle (scanner/src/geheim.js). Den, der har webserveren, databasen eller en sikkerhedskopi, har kun krypteret tekst.
2. Grænsefladen viser kun det første tegn og længden af brugernavnet (cfg/login_lib.php). Adgangsoplysninger vises aldrig, logges aldrig og udleveres aldrig via API'et.
3. Ved en kontrol knytter applikationen den krypterede tekst til jobbet. Kontroltjenesten dekrypterer den, rydder straks feltet i jobbet og overdrager kun adgangsoplysningerne til containeren via standardinput, aldrig som kommandolinjeargumenter (scanner/src/worker.js). Rester i afbrudte job ryddes af statusprocessen efter én time (cfg/login_lib.php).
4. I containeren logger browseren ind. Den afbryder, hvis loginsiden omdirigerer til en anden host, hvis loginformularen har en CAPTCHA (vi omgår ikke CAPTCHA'er), eller hvis et adgangskodefelt stadig er synligt efter indsendelse (scanner/src/login.js). Derefter rydder den adgangskodefeltet i sidens hukommelse og glemmer adgangsoplysningerne (scanner/src/login.js).
5. Den læser højst fem sider på samme domæne, som Kunden har angivet. Adresser med ord for at logge ud, slette, fjerne eller opsige er spærret (scanner/src/login.js). Bag login indsendes intet, der tages ingen skærmbilleder, og cookies og links havner ikke i resultatet (scanner/src/login.js).
6. Sletningen er endelig: den krypterede tekst overskrives med tilfældige data af samme længde, rækken slettes, og ventende job ryddes (cfg/login_lib.php). Når domænet slettes, forsvinder rækken automatisk via en fremmednøgle.

6.6 Leveringskontrol

Leveringskontrollen besvarer spørgsmålet om, hvorvidt en e-mail fra kontaktformularen virkelig når frem, og evaluerer dens ægthedskendetegn. Den er valgfri, slået fra som standard og kræver, at der er sat en kontrolpostkasse op (cfg/zustellung_lib.php).

1. Hvis Kunden slår den til, får domænet et tilfældigt mærke. Kunden indtaster kontroladressen med dette mærke som bcc i sin formular.
2. Fra da af går enhver formular-e-mail også til kontrolpostkassen: vores markerede testindsendelser og alle rigtige beskeder fra besøgende. E-mailene går direkte til postkassen hos Namecheap, Inc. (Private Email), Phoenix, Arizona, USA – de når kun frem, hvis MX-posterne for vores domæne peger dertil; via videresendelse, f.eks. hos domæneregistratoren Namecheap, Inc., når de ikke postkassen – og bliver dér, indtil de hentes.
3. Statusprocessen henter postkassen hvert femte minut (srv/cron_status.php). For hver e-mail læser den headerne og højst de første 8 KB af teksten uden at markere dem som læst (cfg/zustellung_lib.php).
4. Ud fra headerne fastslår den mærket og dermed domænet og ud fra teksten i givet fald identifikatoren for vores test (cfg/zustellung_lib.php). Det, der gemmes, er tidspunktet, domænet og i givet fald testidentifikatoren (cfg/zustellung_lib.php), i 180 dage (cfg/zustellung_lib.php).
5. Ud fra headerne evaluerer den SPF, DKIM og DMARC og gemmer resultatet ved domænet: kontrolresultaterne, domænet for afsenderadressen, domænerne for signaturerne og adressen på den afsendende mailserver (cfg/zustellung_lib.php). Hvis resultatet forværres, sendes der én gang en alarm til Kunden, som kan nævne afsenderdomænet (cfg/zustellung_lib.php).
6. Derefter markerer den enhver hentet e-mail til sletning, også en, der ikke kunne tildeles noget domæne, og fjerner den fra postkassen ved kørslens afslutning (cfg/zustellung_lib.php). Hvis kørslen afbrydes forinden, bliver e-mailene liggende indtil næste vellykkede kørsel.
7. Kun kopien af netop den pågældende test gælder som bevis for levering (cfg/zustellung_lib.php). Hvis den ikke når frem inden for tre timer (delivery_wait_h), rapporterer tjenesten »Levering mangler«.

Teksten i rigtige beskeder skrives aldrig til databasen, og det gør den besøgendes adresse heller ikke. Begge læses dog: hentningen indlæser de første 8 KB af hver e-mail i hukommelsen for at søge efter testidentifikatoren.

6.7 Sværmbeskyttelse

1. WordPress-pluginets beskyttelseslag stopper en besked som spam og tæller domænerne for linkene i den. Én gang om dagen rapporterer pluginet disse domæner med deres antal hits til os, højst 60 pr. dag; ingen adresser, ingen tekst, ingen IP-adresser (cfg/swarm_lib.php).
2. Én gang om dagen sammenstiller vi listen ud fra dette: et domæne kommer på den, hvis det inden for syv dage er rapporteret af mindst tre forskellige websteder og med mindst fem hits (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). Store tjenester fra en fast undtagelsesliste og vores Kunders domæner, i begge tilfælde inklusive underdomæner, kommer aldrig på listen (cfg/swarm_lib.php).
3. Listen sendes til alle forbundne websteder med svaret på den daglige rapport. Deres beskyttelseslag flytter beskeder med links til listede domæner i karantæne, ikke i papirkurven.
4. Det, der ikke længere optræder på den nye liste, falder ud; rapporter slettes efter 30 dage (cfg/swarm_lib.php).
5. IP-netværk (/24 eller /48) er forberedt, men slået fra, indtil den juridiske gennemgang er afsluttet (cfg/swarm_lib.php).

6.8 Brug af kunstig intelligens

En sprogmodel kører på vores egen scanserver, ikke hos en AI-udbyder. Den bruges to steder: i kontroltjenesten klassificerer den formularer, hvis type reglerne ikke genkender; den ser i den forbindelse sidetitlen, sideadressen, etiketterne på indsendelsesknapperne, felttyper, navne, etiketter og pladsholdere samt op til 400 tegn formulartekst (scanner/src/classify.js). Den spørges kun, hvis reglerne returnerer »ukendt«; formularer, der klassificeres på denne måde, indsendes aldrig og tæller ikke med i score og bedømmelse. Score, bedømmelse, forebyggelse af misbrug, sværmbeskyttelse og spamregler er faste regler, ikke AI. I »Fix it for me« omskriver den indsat formularkode; koden gemmes ikke. Modellen træffer ingen afgørelser om personer. Mere herom på siden EU's AI-forordning: Sådan bruger formexposed AI.

6.9 Retsgrundlag

Behandlingsaktivitet	Retsgrundlag
P1 Gratis kontrol: kontrol af det anmodede domæne; grænser og forebyggelse af misbrug	i forhold til den anmodende person Art. 6(1)(b); i forhold til operatøren og afbildede personer Art. 6(1)(f); forebyggelse af misbrug Art. 6(1)(f)
P2 Kontrol af potentielle kunder	Art. 6(1)(f) (bureauets og formexposeds legitime interesse)
P3 Undersøgelse	Art. 6(1)(f)
P4 Kontrol af Kundedomæner	Art. 6(1)(b) i forhold til Kunden; for tredjepartsdata på dennes websted Kundens instruks efter Art. 28
P5 Scanning bag login	Kundens instruks efter Art. 28; Kundens retsgrundlag
P6 Leveringskontrol	Kundens instruks efter Art. 28; Kundens retsgrundlag (i vores tekstforslag til Kunder Art. 6(1)(f))
P7 Sværmbeskyttelse	Art. 6(1)(f) (fælles forsvar mod spam på tværs af mange websteder)

Vores legitime interesse i P1 til P3 består i at vise operatører og deres tjenesteudbydere svagheder i deres formularer, før de udnyttes til spam eller misbrug, og i at levere tjenesten. Dataene stammer fra offentligt tilgængelige kilder. Interesseafvejningen er beskrevet i afsnit 7; om Art. 6(1)(f) bærer kontrol af tredjeparters websteder efter anmodning, er et åbent spørgsmål til den juridiske gennemgang.

6.10 Modtagere og overførsler til tredjelande

Modtager	Hvad	Behandlingsaktivitet	Status
Ingen uden for formexposed	Kontrolresultater, skærmbilleder, klassificering foretaget af sprogmodellen	P1–P5	Kontroltjenesten og sprogmodellen kører på vores egne servere; i crawlerens kontrolforløb blev der ikke fundet noget kald til en tredjepart ud over til selve det kontrollerede websted, til de tjenester, hvis indhold det indlejrer (som ved enhver besøgende), og til RDAP-tjenesten rdap.org for domænets alder (kun domænenavnet); overvågningsfunktionerne er anført i næste række
Enhver, der kender linket	Rapport med fund og skærmbilleder	P1, P2, P4	tilfældigt link med 128 bit (cfg/check_lib.php), sider med noindex (www/report.php)
Tjenester, som overvågningen af et Kundedomæne forespørger	DNS-blokeringslister (SpamCop, PSBL, Mailspike, SURBL): domæner og IP-adresser på servere, ingen besøgsdata; Google Web Risk kun, hvis det er sat op: adressen på forsiden; tidsstemplingsmyndighederne Certum og DigiCert: kun en hashværdi af bevisloggen; RDAP via IANA-registret: kun domænenavnet; udbydernes statussider: der overføres intet; wpvulnerability.net: identifikatoren for et plugin (uden version) eller tema og WordPress-versionen	P4	i brug; detaljer i Fortegnelsen over behandlingsaktiviteter og på siden Underdatabehandlere
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Kontrolkopier inklusive rigtige besøgendes beskeder	P6	Kontrakt endnu ikke indgået; behandlingssted og overførselsmekanisme skal stadig undersøges
Namecheap, Inc. (USA)	Registrator og DNS; indtil postkassen er sat op, videresendelse af generelle e-mails til adresser på vores domæne, ikke af kontrolkopierne (de når kun postkassen via MX-poster, der peger direkte på den)	– (ingen kontrolkopier)	Overførselsmekanismen skal undersøges
Alarmkanaler valgt af Kunden (e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Hændelse, domæne, link; ved ægthedskontrollen afsenderdomænet, hvis det ikke tilhører webstedet	P4, P6	mål valgt af Kunden; delvis uden for EU. Telegram-beskeder sender vi via vores bot; overførselsmekanismen herfor er et åbent spørgsmål til den juridiske gennemgang
Alle forbundne websteder	Liste over linkdomæner	P7	via svaret til pluginet
Anden sonde	Domæne, formularadresse, selektor, trin	P4	slået fra

6.11 Opbevaring, målt, ikke tilsigtet

Sletning sker for det meste om natten kl. 03.00 i statusprocessen (srv/cron_status.php, cfg/fristen_lib.php); rapporter i sværmbeskyttelsen og rækker for potentielle kunder slettes dagligt fra kl. 04.00, tildelinger i leveringskontrollen ved hver hentning; anonyme rapporter og rapporter om potentielle kunder slettes via deres udløbsdato (cfg/check_lib.php). Skærmbilleder slettes fra disken sammen med deres scanning (cfg/fristen_lib.php).

Data	Periode ifølge koden	Kildehenvisning	Resultat
Gratis kontrol inklusive billeder	30 dage	cfg/check_lib.php	virksom
Kontrol af potentielle kunder inklusive billeder	90 dage	cfg/akquise_lib.php; srv/cron_status.php (rækker for potentielle kunder)	virksom
Kontroller af et Kundedomæne	13 måneder; den seneste bevares, så længe domænet findes	cfg/fristen_lib.php	virksom
Resultater af browserforløb inklusive sværtede billeder	13 måneder	cfg/fristen_lib.php	virksom
Data for et slettet domæne	straks; forældreløse data om natten	cfg/fristen_lib.php (fe_domain_loeschen(), fe_fristen_lauf())	virksom, herunder scriptoversigten og scriptændringerne, som ud over dette ikke har nogen egen opbevaringsperiode (se Fortegnelsen over behandlingsaktiviteter)
Undersøgelse: rådata inklusive billeder	ved offentliggørelse	cfg/studie_lib.php	uden offentliggørelse ingen tidsbegrænsning; listen over kontrollerede hosts bevares uden tidsbegrænsning også efter offentliggørelse
Interne kontroller uden domæne og uden rapport	ingen	–	ingen sletning; målt: 85 kontroller med 369 billeder siden 22. september 2026 (R4)
Tildelinger i leveringskontrollen	180 dage	cfg/zustellung_lib.php	virksom
Resultat af ægthedskontrollen ved domænet	indtil næste resultat eller sletningen af domænet	cfg/zustellung_lib.php	overskrives, ikke tidsbegrænset
Kontrolkopier i postkassen	indtil næste vellykkede hentning (interval på fem minutter)	cfg/zustellung_lib.php	kopier og sikkerhedskopier hos postkasseudbyderen ikke verificeret
Adgangsoplysninger til scanningen bag login	indtil sletning foretaget af Kunden eller sletning af domænet; i jobbet højst indtil kørslens afslutning, rester efter én time	cfg/login_lib.php	virksom; i sikkerhedskopier kun som krypteret tekst i op til 14 dage
Rapporter i sværmbeskyttelsen	30 dage	cfg/swarm_lib.php	virksom
Grænser for den gratis kontrol (IP, land, sessionshash)	7 dage	srv/cron_status.php	virksom
Noter om påfaldende adfærd med IP-adresse	90 dage efter løsning	srv/cron_status.php	uløste noter uden tidsbegrænsning; målt: 3 noter, alle løst
IP-adresse, land, browser i forbindelse med en opt-out	12 måneder; udelukkelsen bevares	cfg/fristen_lib.php	virksom
Sikkerhedskopier af databasen	14 dage	cfg/backup_lib.php	virksom; sikkerhedskopierne opbevares i øjeblikket samme sted som databasen og er ikke krypteret separat; en krypteret kopi på en anden placering er planlagt (R13)

7. (b) Vurdering af nødvendighed og proportionalitet

Målestokken er de angivne formål: at vise operatører, om deres formularer er beskyttet mod spam og misbrug (P1 til P5), at kontrollere, om formular-e-mails når frem og fremstår ægte (P6), og i fællesskab at forsvare sig mod spam på tværs af mange websteder (P7). Disse formål er legitime. Spørgsmålet efter Art. 35(7)(b) er snævrere: er denne behandling nødvendig i denne dybde for formålet, og står indgrebet i et rimeligt forhold til fordelen?

Komponent	Nødvendig for formålet?	Proportional i den form, den er bygget?
Hentning af nogle få offentlige sider, formularernes struktur, registrerede beskyttelsesforanstaltninger	Ja. Uden dem intet resultat.	Ja. Højst otte sider (plus visningerne fra afsnit 6.1), et forbud mod forsiden i robots.txt respekteres, ingen værdier fra synlige felter, modtageradresser kun som domæne.
Skærmbillede pr. formular	Ja, som dokumentation i rapporten: operatøren kan se, hvilken formular der menes.	I vid udstrækning. Felterne er tomme, fordi crawleren ikke indtaster noget. Billedet viser dog omgivelserne af formularelementet uden at sværte noget (R3).
Skærmbillede af forsiden	Ikke nødvendigt for selve resultatet. Det tjener til genkendelse af det kontrollerede websted i rapporten.	Kun i begrænset omfang; yderligere minimering planlagt. Forsider viser ofte personer: teamfotos, kontaktpersoner, kundeudtalelser med navne. Se R3 og afsnit 9.3.
Læsning af værdierne i skjulte felter (de første 24 tegn, kun under kontrollen)	Ja: tokens og tidsstempler genkendes ud fra dem.	Ja. Kun genkendelsesresultatet gemmes, ikke værdien, også bag login (R8).
Svarside på testindsendelsen (billede og 300 tegn tekst)	Ja, som dokumentation for, hvordan formularen reagerede.	Ja. Svaret vedrører vores markerede testbesked uden personoplysninger.
Klassificering foretaget af sprogmodellen	Nyttig, ikke nødvendig: uden den forbliver flere formularer »ukendt«.	Ja. Lokalt, uden videregivelse, uden ret til at indsende.
Aktive testindsendelser	Ja. Om en beskyttelse virker, viser sig først, når den testes.	Ja, med loft og markering. Forudsætningen – bevis for kontrol – fornys dog aldrig (R7).
Søgning efter eksponerede filer	Ja for Kunden, hvis formulardata kan være eksponeret dér.	Ja. Kun verificerede domæner, højst 8 KB, indholdet gemmes aldrig.
Scanning bag login	Ja for formularer i medlemsområdet, som ellers ville forblive ukontrollerede.	I vid udstrækning. Kryptering og sletning er omhyggeligt bygget; login accepterer dog ukrypterede forbindelser og fejlbehæftede certifikater (R8).
Kontrolkopi af rigtige besøgendes beskeder	Ikke for beviset for levering. Det beror kun på kopien af vores test (cfg/zustellung_lib.php). Rigtige beskeder kommer med, fordi en bcc i formularen ikke skelner mellem test og rigtig besked. De er nyttige for ægthedskontrollen (SPF, DKIM, DMARC), fordi de viser den faktiske afsendelsesvej.	Delvis. Indholdet gemmes ikke, men læses, og det bliver hos postkasseudbyderen, hvis kontrakt stadig er uafklaret, indtil hentningen (R1, R2). Et mindre indgribende design er teknisk muligt: med vores plugin kunne bcc'en begrænses til markerede testbeskeder (afsnit 9.3).
Lagring af afsenderdomænet for rigtige beskeder	Delvis: det viser, om formularen sender med den besøgendes adresse som afsender (en hyppig årsag til at blive klassificeret som spam).	Betinget. For en privatperson med eget domæne er domænet en personoplysning, og det indgår i alarmen til Kunden og dennes kanaler (R1).
Fælles liste over linkdomæner	Ja. Et spamlink, der optræder på mange websteder samtidig, er et stærkt signal, som et enkelt websted ikke har.	Ja, med minimumstal, undtagelser og karantæne i stedet for sletning. IP-netværk ville ikke være proportionale uden en ny vurdering.
Rådata fra undersøgelsen	Indtil evalueringen, ja.	Uden en maksimal periode, nej (R4).
Rapport under et tilfældigt link	Ja. At give rapporten videre – f.eks. til den tjenesteudbyder, der passer webstedet – er formålet med den gratis kontrol.	Ja. Tilfældigt link med 128 bit, noindex, gratis rapport kun som uddrag (cfg/check_lib.php, FE_FREE_DETEKTOREN), sletning efter 30 dage.

Lovlighed. For P1 til P3 og P7 støtter vi os på Art. 6(1)(f). Til fordel i afvejningen taler: dataene er offentlige og hentes på samme måde, som enhver besøgende gør; intet indsendes; personoplysninger er tilfældige og ubetydelige; perioderne er korte; operatøren kan udelukke yderligere kontroller fra crawleren gennem et forbud mod forsiden i robots.txt og enhver yderligere kontrol via vores opt-out-side, straks og uden bevis; fordelen – en beskyttet formular – kommer også operatøren og dennes besøgende til gode. Imod taler: operatøren får intet at vide om kontrollen, rapporten er beregnet til tredjeparter, og for enkeltmandsvirksomheder vurderer den en person. Vi anser afvejningen for forsvarlig, så længe foranstaltningerne i afsnit 9.1 opretholdes; en juridisk bekræftelse udestår.

Oplysning til de registrerede (Art. 13 og 14). Vi informerer operatører og personer på kontrollerede sider via crawlersiden, som er nævnt i identifikatoren ved hver hentning, via Privatlivspolitikken og via opt-out-siden. At informere personer, der tilfældigt optræder på et skærmbillede, individuelt ville kun være muligt, hvis vi identificerede dem – hvilket ville være et yderligere og mere alvorligt indgreb. I det omfang støtter vi os på Art. 14(5)(b). Besøgende, hvis beskeder passerer gennem kontrolkopien, informeres af Kunden; Databehandleraftalen kræver dette, og vi stiller en tekstblok til rådighed til formålet.

Dataminimering (Art. 5(1)(c)). Den er synlig mange steder og forankret i koden: ingen feltværdier, modtageradresser kun som domæne, kontoidentifikatorer i scriptadresser skjult, intet indhold fra kontrolkopien i databasen, ingen skærmbilleder bag login, kun domæner i sværmbeskyttelsen. To steder er yderligere minimering mulig og planlagt (afsnit 9.3): for skærmbilledet af forsiden uden sværtning og for afsenderdomænet for rigtige beskeder.

Opbevaringsbegrænsning (Art. 5(1)(e)). Siden 27. september 2026 har den natlige kørsel overholdt perioderne i Privatlivspolitikken for Kundedata og rydder data uden tilknyttet domæne, der er tilbage fra perioden før da (cfg/fristen_lib.php). To veje uden tidsbegrænsning står stadig åbne: interne kontroller og ikke-offentliggjorte undersøgelser (R4).

Rigtighed (Art. 5(1)(d)). Et resultat kan være forkert: en formular fremstår ubeskyttet, fordi beskyttelsen først indlæses efter en interaktion, eller crawleren blev behandlet anderledes af en firewall end en besøgende. For en operatør, hvis websted offentligt videregives som »Eksponeret«, er det et spørgsmål om omdømme. Rapporten nævner derfor metoden, viser dokumentation og gør opmærksom på begrænsningerne ved en kontrol udefra.

Resultat vedrørende proportionalitet: Kontrollen af tredjeparters og egne websteder er i den form, den er bygget, i det væsentlige proportional. Tre steder er der behov for forbedringer, som kan afhjælpes med almindelige midler, og for hvilke der er planlagt foranstaltninger (afsnit 9.3): skærmbillederne af forsiden, de interne kontroller uden tidsbegrænsning og det ukrypterede login ved scanningen bag login. Leveringskontrollen er proportional for testkopien og for ægthedskontrollen; for rigtige besøgendes beskeder holder den kun, så længe deres indhold ikke gemmes, vejen via postkasseudbyderen er kontraktligt sikret, og Kunden informerer sine besøgende. I dag mangler det andet af disse tre punkter.

8. (c) Vurdering af risiciene for de registreredes rettigheder og frihedsrettigheder

Det, der vurderes, er risikoen for de registrerede, ikke for formexposed. Sandsynligheden bedømmes som fjern, mulig, sandsynlig eller indtruffet; »indtruffet« betyder, at hændelsen ikke er en prognose, men en målt tilstand. Alvoren bedømmes som begrænset, betydelig, alvorlig eller meget alvorlig, afhængigt af hvad personen risikerer at miste: fortroligheden af sin besked, kontrollen over en konto, sit forretningsmæssige omdømme, muligheden for at udøve en rettighed. Niveauet følger af begge og beskriver den nuværende tilstand med foranstaltningerne fra afsnit 9.1.

Nr.	Risiko	Behandlingsaktivitet	Sandsynlighed	Alvor	Niveau
R1	Rigtige besøgendes beskeder i kontrolkopien, herunder mulige særlige kategorier	P6	Indtruffet, når funktionen er slået til	Alvorlig	Høj
R2	Kontrolkopiens vej via postkasseudbyderen uden indgået kontrakt og med mulig tredjelandsforbindelse	P6	Sandsynlig, så længe kontrakten mangler	Alvorlig	Høj
R3	Skærmbilleder af tredjeparters websteder uden sværtning	P1–P4	Sandsynlig	Begrænset	Middel
R4	Kontroldata og skærmbilleder uden sletningsrute	P3, interne kontroller	Indtruffet	Betydelig	Høj
R5	Kontrol og offentlig bedømmelse af tredjeparters websteder uden operatørens viden; misbrug som rekognosceringsværktøj	P1	Mulig	Betydelig	Middel
R6	Kontrol af potentielle kunder som grundlag for uopfordrede henvendelser	P2	Sandsynlig	Begrænset	Middel
R7	Bevis for kontrol fornys aldrig	P4, P5	Mulig	Betydelig	Middel
R8	Adgangsoplysninger og indhold ved scanningen bag login	P5	Mulig	Alvorlig	Middel; høj for rigtige konti
R9	Aktive testindsendelser og filkontrol på Kundens websted	P4	Fjern	Betydelig	Lav
R10	Klassificering foretaget af en sprogmodel	P1–P4	Fjern	Begrænset	Lav
R11	Fælles spærreliste ud fra rapporter fra mange websteder	P7	Mulig	Begrænset	Lav til middel; høj med IP-netværk
R12	Rapporter og skærmbilleder under et offentligt link	P1, P2, P4	Mulig	Begrænset	Lav
R13	Svagheder i infrastrukturen: sikkerhedskopier, serveradgang, scanserver	alle	Mulig	Alvorlig	Høj
R14	De registreredes rettigheder for personer, der ikke kender os	P1–P6	Sandsynlig	Begrænset	Lav

R1 – Rigtige besøgendes beskeder i kontrolkopien

Dette er tjenestens alvorligste risiko, og den opstår ikke af en fejl, men af designet. En bcc i formularen skelner ikke mellem vores testbesked og en besøgendes besked. Hvis en Kunde slår leveringskontrollen til, når enhver besked, der sendes via denne formular, vores kontrolpostkasse (cfg/zustellung_lib.php). Hentningen læser headerne og de første 8 KB af teksten ind i hukommelsen for at søge efter vores testidentifikator (cfg/zustellung_lib.php). For en almindelig kontaktformular betyder det navn, e-mailadresse, telefonnummer og hele beskeden.

Hvad den besøgende skriver, er op til vedkommende, og feltet indbyder til personligt indhold: en tidsbestilling med beskrivelse af symptomer til en lægepraksis, en redegørelse for en retstvist til et advokatfirma, en jobansøgning, en henvendelse om et barn til en skole. Vores juridiske dokumenter siger, at kopier »ikke bør indeholde særlige kategorier af personoplysninger«. Det er en anmodning til Kunden, ikke en beskyttelsesforanstaltning: hverken Kunden eller vi ved på forhånd, hvad en besøgende vil skrive.

Hertil hører to sideveje. For det første gemmer ægthedskontrollen domænet for afsenderadressen ved domænet (cfg/zustellung_lib.php). Hvis formularen sender med den besøgendes adresse som afsender, er det den besøgendes domæne – uden betydning for en stor mailudbyder, men en personoplysning for en privatperson med eget domæne. Dette domæne optræder også i alarmen, der går til Kunden og til de kanaler, Kunden har valgt (cfg/zustellung_lib.php). For det andet gemmer den adressen på den afsendende mailserver (cfg/zustellung_lib.php); som regel er det webstedets server, ikke den besøgendes.

Sandsynlighed – indtruffet, når funktionen er slået til. Spørgsmålet er ikke, om der kommer rigtige beskeder, men hvor mange. Målt på udviklingssystemet er funktionen ikke slået til for noget domæne. Alvor – alvorlig. Fortroligheden af en besked til en virksomhed betyder noget for mange mennesker, og for nogle af de typiske Kunder må der forventes data efter Art. 9. Alvoren mildnes af, at indholdet ikke havner i databasen, kun ligger kortvarigt i postkassen og ikke læses af nogen person hos formexposed. Niveau – højt.

R2 – Kontrolkopiens vej via postkasseudbyderen uden indgået kontrakt

Før vores hentning ser en kontrolkopi, ligger den i postkassen hos Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Den når kun frem dertil, hvis MX-posterne for vores domæne peger direkte på denne postkasse; videresendelse hos domæneregistratoren Namecheap, Inc. er ikke en station for kontrolkopierne (via videresendelse når de ikke postkassen). For den station, der er tilbage, er de kontraktlige forhold stadig uafklarede: kontrakten med postkasseudbyderen er ikke indgået, dens lagringssteder, underdatabehandlere og perioder for sikkerhedskopier er ikke fastlagt, og det er uafklaret, om en afgørelse om tilstrækkeligt beskyttelsesniveau eller standardkontraktbestemmelser er påkrævet for dens behandlingssted og finder anvendelse. For vores egne transaktionelle e-mails er dette et spørgsmål om kontraktudformning. For kontrolkopierne er det mere alvorligt: dér er der tale om data, vi modtager som databehandler, og enhver tjenesteudbyder på vejen er en underdatabehandler, som vi hæfter for efter Art. 28(4).

Desuden gælder »slettet efter hentning« kun for vores visning af postkassen. Om udbyderen opbevarer slettede e-mails i sine egne sikkerhedskopier eller i en papirkurv, og hvor længe, er ikke verificeret. Hvis en hentning afbrydes, bliver e-mailene liggende indtil næste vellykkede kørsel (cfg/zustellung_lib.php); hvis statusprocessen svigter, bliver de liggende på ubestemt tid. Endelig er sikringen af selve hentningen et af de punkter, der skal kontrolleres på produktionssystemet før lanceringen (afsnit 9.3).

Sandsynlighed – sandsynlig, så længe kontrakten mangler: enhver kontrolkopi tager denne vej. Alvor – alvorlig af samme grunde som R1. Niveau – højt. Applikationens opsætningstjekliste rapporterer den manglende postkasse som en advarsel; der findes ingen spærre, der blokerer leveringskontrollen uden en dokumenteret kontrakt.

R3 – Skærmbilleder af tredjeparters websteder uden sværtning

Crawleren tager et skærmbillede af det synlige område af den første side og et billede af formularelementet for hver synlig formular (scanner/src/crawl.js). Der sværtes intet i den forbindelse. Det er anderledes ved browserforløb: dér maskeres inputfelter før skærmbilledet (scanner/src/browser.js). Kun billederne fra browserforløb er altså »rensede«, ikke crawlerens og ikke billedet af svarsiden fra en aktiv kontrol.

Fordi crawleren ikke indtaster noget, er formularfelterne tomme. Forsiden for en lille virksomhed viser dog ofte indehaveren, teamet, kundeudtalelser med navne og fotos eller et chatvindue med billedet af en medarbejder. Alt dette er offentligt; skærmbilledet gør det til en kopi, der gemmes hos os, vises i rapporten og kan gives videre med linket.

Sandsynlighed – sandsynlig. Der blev målt 432 skærmbilleder i udviklingssystemets datasæt. Alvor – begrænset: indholdet er allerede offentligt, og perioderne for kontroller uden konto er korte. Niveau – middel, fordi de afbildede personer intet ved, og billedet af forsiden ikke er nødvendigt for resultatet.

R4 – Kontroldata og skærmbilleder uden sletningsrute

Den natlige kørsel sletter kontroller ad to veje: via udløbsdatoen for en rapport (cfg/check_lib.php) og via perioden for kontroller af et Kundedomæne (cfg/fristen_lib.php, kun for kontroller med domæne). En kontrol, der hverken har en rapport eller et domæne, falder gennem begge net. Det er kontrollerne med tillidsniveauet »intern«: undersøgelser og kontroller, som udbyderen opretter fra kommandolinjen.

• Undersøgelser sletter deres rådata ved offentliggørelsen (cfg/studie_lib.php). Hvis en undersøgelse aldrig offentliggøres – fordi den har for få websteder med en formular (cfg/studie_lib.php nægter så offentliggørelse), eller fordi den bliver liggende – bevares kontroller, formularer, fund og skærmbilleder uden tidsbegrænsning.
• Interne kontroller fra kommandolinjen har overhovedet ingen sletningsrute. Målt den 11. oktober 2026: 85 sådanne kontroller af tredjeparters websteder med 978 formularer og 369 skærmbilleder, den ældste fra 22. september 2026, ingen med rapport eller domæne.
• Noter om påfaldende adfærd i den gratis kontrol indeholder IP-adressen og slettes 90 dage efter, at de er løst (srv/cron_status.php). En note, der aldrig løses, bevares. Målt: tre noter, alle løst.

Sandsynlighed – indtruffet. De 85 kontroller er ikke et scenarie, men eksisterende data. På udviklingssystemet er det kontroller fra en feltafprøvning; samme kode gælder på produktionssystemet. Alvor – betydelig: der findes ingen opbevaringsperiode for disse data. Med hensyn til princippet om opbevaringsbegrænsning (Art. 5(1)(e)) er det et åbent punkt med en planlagt foranstaltning (afsnit 9.3, prioritet »først«), og det berører netop personer, der intet ved om kontrollen. Interne kontroller er beskrevet i Fortegnelsen over behandlingsaktiviteter; Privatlivspolitikken nævner dem endnu ikke særskilt (afsnit 9.4). Niveau – højt.

R5 – Kontrol og offentlig bedømmelse af tredjeparters websteder uden operatørens viden

Enhver kan få et hvilket som helst offentligt tilgængeligt websted kontrolleret, uden konto og uden nogen tilknytning til det. Operatøren underrettes ikke. Resultatet er en rapport, der bedømmer webstedet som »Eksponeret«, »Delvist beskyttet« eller »Beskyttet«, og som alle med linket kan se. For de registrerede er to konsekvenser tænkelige. En enkeltmandsvirksomhed får offentligt – om end kun for modtagerne af linket – en bedømmelse, der kan være et fejlagtigt resultat. Og rapporten viser en spammer, hvilken formular der kan udfyldes uden hindringer.

Heroverfor står en række spærringer (cfg/check_lib.php): højst én kontrol pr. domæne på syv dage, derefter samme rapport; grænser pr. IP-adresse og session; et dagsloft for hele tjenesten; ingen kontroller af meget nye domæner, som er typiske for misbrug; en note og et signal ved påfaldende adfærd; robots.txt og opt-out, kontrolleret to gange (cfg/check_lib.php og i kontroltjenesten). Den gratis rapport er et uddrag: den viser kun de grundlæggende fund, ikke dokumentationen fra alle detektorer. Og den siger intet, som en bot ikke selv kunne finde ud af på få sekunder – en ubeskyttet formular er synlig udefra.

Sandsynlighed – mulig. Alvor – betydelig for en enkeltmandsvirksomhed, hvis formular bliver mål efter en rapport, eller hvis bedømmelse er forkert. Niveau – middel.

R6 – Kontrol af potentielle kunder som grundlag for uopfordrede henvendelser

I grænsefladen beskrives kontrollen af potentielle kunder som en »døråbner til den første samtale«. Hvordan bureauet bruger det korte resultat, afgør bureauet; teknisk kan det også sende det til en operatør, der ikke har bedt om det. Vi kontakter ingen (cfg/akquise_lib.php), og Servicevilkårene forpligter bureauet til at overholde reglerne om reklame og markedsføring. En uopfordret e-mail med resultatet er dog direkte markedsføring, også mellem virksomheder, og kræver i Polen (Art. 398 i loven om elektronisk kommunikation (Prawo komunikacji elektronicznej, PKE)) og i Tyskland (§ 7(2) i den tyske lov mod illoyal konkurrence (Gesetz gegen den unlauteren Wettbewerb, UWG)) forudgående samtykke. Grænsefladen gør ikke opmærksom på dette; teksterne i kontrollen af potentielle kunder taler kun om »passiv« og »opt-out-liste«.

Sandsynlighed – sandsynlig, fordi funktionen tjener kundeerhvervelse, og vi ikke kan kontrollere, om modtageren har givet samtykke. Alvor – begrænset: for operatøren er det en irriterende markedsføringsmail med en bedømmelse af vedkommendes websted. Niveau – middel. Risikoen ligger i bureauets adfærd; fordi funktionen kommer fra os, er en henvisning i grænsefladen planlagt (afsnit 9.3).

R7 – Bevis for kontrol fornys aldrig

Aktive testindsendelser, søgningen efter eksponerede filer og scanningen bag login forudsætter, at Kunden har bevist, at den har ret til at kontrollere domænet. Dette bevis kontrolleres én gang (cfg/verify_lib.php) og aldrig igen. Der findes ingen rute i koden, hvorved et domæne mister sit bevis. Hvis domænet skifter ejer, et bureau afslutter sit mandat, eller operatøren fjerner DNS-posten, fortsætter kontrollerne – op til dagligt, med op til fem testindsendelser og, hvor det er gemt, med login på en testkonto, som den nye operatør måske ikke kender til. Hvad der derimod ikke er muligt, er at overføre beviset til en anden host ved omdøbning: værtsnavnet på et domæne med bevis for kontrol kan ikke ændres.

Sandsynlighed – mulig: skift af domæne og mandat er hverdag for bureauer. Alvor – betydelig for den nye operatør og dennes medarbejdere, som modtager markerede testbeskeder, og hvis websted gennemsøges for eksponerede filer uden deres samtykke. Niveau – middel. Testbeskederne forklarer sig selv og henviser til crawlersiden og opt-out; opt-out virker også mod kontroller fra Kunder.

R8 – Adgangsoplysninger og indhold ved scanningen bag login

Krypteringen af adgangsoplysningerne er omhyggeligt bygget: webserveren kan ikke længere læse dem efter lagring, databasen og sikkerhedskopien indeholder kun krypteret tekst, posten er bundet til sit domæne, adgangsoplysningerne kommer kun ind i containeren via standardinput og ryddes derefter fra hukommelsen (afsnit 6.5). To huller er tilbage; et tredje punkt vedrører kun læsning, ikke lagring.

• Ukrypteret login er tilladt. Adressekontrollen tillader http ved siden af https (cfg/login_lib.php, scanner/src/login.js). Hvis Kunden angiver en loginside med http, sendes brugernavn og adgangskode i klartekst over internettet ved hver kontrol.
• Certifikatfejl stopper ikke login. Login afbrydes i øjeblikket ikke, når certifikatet for Kundens side er ugyldigt (scanner/src/login.js). Certifikatet beskytter derfor ikke fuldt ud adgangsoplysningerne på vej til Kundens side. Afbrydelse ved certifikatfejl er planlagt (afsnit 9.3, prioritet »først«).
• Værdier i skjulte felter bag login læses, men gemmes ikke. Crawleren læser de første 24 tegn af værdien i skjulte felter (scanner/src/crawl.js), og samme udtræksfunktion kører bag login (scanner/src/login.js). Dér indeholder skjulte felter ofte et kontonummer, en brugeridentifikator eller e-mailadressen for den indloggede konto; i feltoversigten og fundene indgår dog kun feltnavn, type, etiket og genkendelsesresultatet.

Hertil kommer det, som koden ikke kan forhindre: Kunden bekræfter, at den bruger en testkonto med så få rettigheder som muligt (cfg/login_lib.php), men den kan indtaste en rigtig administratorkonto. Hvilke sider scanneren derefter læser, bestemmer Kunden; adresser med ord for at logge ud og slette er spærret, men andre handlinger, som et websted udløser via en simpel forespørgsel, er det ikke.

Sandsynlighed – mulig. Alvor – alvorlig, hvis en konto med vide rettigheder berøres; medlemsområdet med alle brugeres data er så åbent. Niveau – middel for en testkonto med få rettigheder, højt for en rigtig konto. Målt på udviklingssystemet er der ikke gemt nogen testkonto.

R9 – Aktive testindsendelser og filkontrol på Kundens websted

En testindsendelse går til de personer, der læser Kundens formular-e-mails – dennes medarbejdere eller en tjenesteudbyder. Den indeholder ingen personoplysninger: afsenderen er dummy@formexposed.com, tekst og emne er markeret og angiver kontrolidentifikatoren (scanner/src/active.js). Risikoen ligger i en fejlklassificering: hvis scanneren tog en ansøgnings-, booking- eller rådgivningsformular for en kontaktformular, ville testbeskeden havne i en proces, der har konsekvenser. Heroverfor står de strenge regler for »indsendbar« (scanner/src/classify.js), spærringen for domæner tilhørende offentlige myndigheder, uddannelsesinstitutioner, klinikker, lægepraksisser, politi og domstole (scanner/src/classify.js) og udelukkelsen af sprogmodellen fra denne afgørelse (scanner/src/classify.js). Fra svaret gemmes status, måladresse, titel, 300 tegn tekst og et billede; de vedrører vores testbesked.

Filkontrollen læser højst 8 KB fra typiske stier. Hvis et databasedump virkelig er eksponeret dér, kan disse 8 KB indeholde formularindtastninger foretaget af besøgende. De kontrolleres kun for en signatur og kasseres (cfg/dateien_lib.php); det, der gemmes, er sti, type og alvorlighed.

Sandsynlighed – fjern. Alvor – betydelig. Niveau – lavt. Målt på udviklingssystemet er der én aktiv kontrol i datasættet uden accepteret indsendelse.

R10 – Klassificering foretaget af en sprogmodel

For formularer, som reglerne ikke genkender, modtager sprogmodellen sidetitel, adresse, knaptekster, feltbeskrivelser og op til 400 tegn formulartekst (scanner/src/classify.js). Det kan omfatte et navn, f.eks. »Din kontaktperson: …«. Den kører på vores egen server; i koden sendes intet til en tredjepart. Om modelsoftwaren logger forespørgsler, er ikke verificeret. Dens resultat bestemmer kun den viste formulartype og kan ikke gøre en formular indsendbar; en forkert klassificering fører til et dårligere resultat, ikke til en handling.

Sandsynlighed – fjern. Alvor – begrænset. Niveau – lavt.

R11 – Fælles spærreliste ud fra rapporter fra mange websteder

Et domæne på listen bevirker, at beskeder med links til det havner i karantæne på alle forbundne websteder. Hvis domænet tilhører en privatperson – en håndværker, en fotograf, en blog – når vedkommendes beskeder med et link til eget websted sent frem til modtagerne. Et sådant domæne kan komme på listen, fordi spammere misbruger det, eller fordi nogen bevidst sender beskeder, der bliver stoppet, med domænet til flere websteder.

Heroverfor står (cfg/swarm_lib.php): mindst tre forskellige websteder og fem hits inden for syv dage; faste undtagelser for store tjenester; aldrig vores Kunders domæner; manuel fjernelse via et værktøj på serveren; karantæne i stedet for sletning; listen genopbygges dagligt, og det, der ikke længere rapporteres, falder ud. De berørte kan ikke se listen og har ingen egen vej til at kræve fjernelse, bortset fra via os.

Sandsynlighed – mulig. Alvor – begrænset, fordi intet går tabt, og modtageren kan frigive beskeden. Niveau – lavt til middel. Med IP-netværk slået til ville netværk hos hele udbydere være berørt, IP-adresser er personoplysninger, og alvoren ville stige til betydelig: højt.

R12 – Rapporter og skærmbilleder under et offentligt link

Rapporter fra den gratis kontrol, kontrollen af potentielle kunder og kontrollerne af Kundedomæner kan tilgås uden login under et tilfældigt link. Linket indeholder 128 bit tilfældighed og kan ikke gættes (cfg/check_lib.php). Siderne har noindex, applikationen sender en referrer-politik, der kun videregiver oprindelsen (www/.htaccess), og skærmbilleder leveres kun sammen med den rapport, de hører til; et andet billednummer returnerer »ikke fundet« (www/shot.php). Risikoen er ikke kryptografisk, men menneskelig: et link gives videre, kopieres ind i en sag, deles i en chat. Hvem der åbner det, registreres kun i loggen over sidevisninger som enhver anden sidevisning (60 dage), hvor selve linket kun optræder i maskeret form; der findes ingen liste over læsere pr. rapport.

Sandsynlighed – mulig. Alvor – begrænset, fordi rapporten kun viser offentlige oplysninger og udløber efter henholdsvis 30 eller 90 dage; rapporter om Kundedomæner forbliver tilgængelige, så længe kontrollen findes (13 måneder, den seneste længere). Niveau – lavt.

R13 – Svagheder i infrastrukturen

Følgende punkter er opført som åbne i vores interne gennemgangspakke og bliver ikke pyntet på her. Vi beskriver dem så præcist, som Kunderne har brug for til deres egen vurdering, men ikke så præcist, at beskrivelsen viser en angriber vejen; detaljerne stiller vi til rådighed for en tilsynsmyndighed efter anmodning.

• Sikkerhedskopier af databasen opbevares i øjeblikket samme sted som databasen og er ikke krypteret separat; en krypteret kopi på en anden placering er planlagt (cfg/backup_lib.php). Indtil da beskytter de ikke mod tab af placeringen, og den, der får fat i databasen, får også fat i sikkerhedskopierne. Adgangsoplysningerne til scanningen bag login er kun indeholdt i dem som krypteret tekst.
• Ingen kryptering af databasen i hvile. Undtagelserne er de felter, der krypteres enkeltvis (adgangsoplysninger til testkontiene, hemmeligheden til anden faktor).
• Forbindelser i vores interne netværk er ikke gennemgående krypteret.
• Serveradministration. Sikkerheden for den administrative adgang til vores servere lever endnu ikke op til den standard, vi tilstræber for driften; hærdningen af serveradministrationen fortsætter.
• Kontrolmiljø. Scanserveren åbner tredjeparters websteder i en browser. Kontrolcontainerne er isolerede – eget netværk, ingen særlige rettigheder, skrivebeskyttede, begrænsede (scanner/src/worker.js). Adskillelsen mellem kontrolmiljøet og tjenestens øvrige dele styrkes yderligere (afsnit 9.3).

Sandsynlighed – mulig. Alvor – alvorlig, fordi alt i en nødsituation ville være berørt på én gang. Niveau – højt. De enkelte punkter kan afhjælpes med almindelige midler (afsnit 9.3).

R14 – De registreredes rettigheder for personer, der ikke kender os

Den, der tilfældigt optræder på et skærmbillede, eller hvis besked passerede gennem en kontrolkopi, ved som regel ikke, at vi findes. Selv hvis vedkommende gør, har vedkommende ingen nøgle til »sine« data: vi gemmer dem ikke efter person, men efter domæne og kontrol. Vi kan kun besvare en anmodning om indsigt efter Art. 15, hvis personen oplyser domænet; vi kan så gennemgå de eksisterende kontroller og billeder. For rigtige besøgendes beskeder er der intet at udlevere, fordi vi ikke gemmer dem – bortset fra afsenderdomænet fra R1. Opt-out virker kun for dem, der driver et domæne, ikke for afbildede personer; for dem er vejen via contact@lukaswojcik.com fortsat åben.

Sandsynlighed – sandsynlig som strukturel situation. Alvor – begrænset, fordi dataene er kortlivede og ikke ordnet efter person. Niveau – lavt.

9. (d) Foranstaltninger til imødegåelse af risiciene

Hver foranstaltning har en status, og statusserne er ikke pynt. Gennemført i dag – verificeret betyder: læst i udviklingssystemets kode og, hvor det er muligt, målt mod databasen. Delvis betyder: mekanismen findes, men opfylder endnu ikke fuldt ud sit formål. Planlagt betyder: foreslået af denne vurdering og ikke bygget; om og hvornår afgøres af indehaveren. Endnu ikke fastlagt er procedurer og beslutninger, som ingen kode erstatter. En konsekvensanalyse, der fremstiller planlagte foranstaltninger som gennemførte, mister sin værdi netop i den situation, hvor der er brug for den.

9.1 Gennemført i dag – verificeret

Foranstaltning	Imødegår	Kildehenvisning
robots.txt læses af crawleren før hver kontrol; en udelukkelse, der omfatter forsiden, en utilgængelig robots.txt eller en serverfejl afslutter kontrollen (understier overholdes ikke enkeltvis; puls, hentning af bevis, header-værktøj og filsøgning læser den ikke)	R5, lovlighed	scanner/src/net.js
Opt-out uden bevis, virksom straks, for domænet og dets www-variant, for anonyme kontroller, potentielle kunder, undersøgelser og Kundekontroller (igangværende overvågning ophører ved den næste planlagte kontrol); kontrolleret to gange (applikation og kontroltjeneste); ophæves kun af os efter anmodning og mod bevis	R5, R7, Art. 21	cfg/check_lib.php; cfg/akquise_lib.php; cfg/studie_lib.php; scanner/src/worker.js
Gratis kontrol: nødstop, reCAPTCHA, én kontrol pr. domæne og uge, grænser pr. IP-adresse og session, dagsloft, ingen nye domæner, kun offentlige adresser, note og signal uden indhold ved anomalier	R5	cfg/check_lib.php
Til grænserne gemmes sessionen kun som hashværdi, aldrig sessionsidentifikatoren	Minimering	cfg/check_lib.php
Ingen feltværdier (begyndelsen af skjulte felter og dataattributter læses kun under kontrollen, afsnit 6.2); modtageradresser kun som domæne; kontoidentifikatorer i scriptadresser skjult	Minimering	scanner/src/crawl.js
Den gratis rapport er et uddrag: kun grundlæggende fund, ingen dokumentation fra alle detektorer	R5	cfg/check_lib.php, FE_FREE_DETEKTOREN
Rapporter under et tilfældigt link på 128 bit, noindex, billeder kun til deres egen rapport, uden for den offentlige webmappe; linket optræder kun i maskeret form i loggen over sidevisninger	R12	cfg/check_lib.php; www/report.php; www/shot.php
Sletning: anonyme rapporter efter 30 dage, potentielle kunder efter 90 dage, Kundekontroller efter 13 måneder (den seneste pr. domæne bevares, så længe domænet findes), dataene for et slettet domæne straks (undtagelser se afsnit 6.11), billederne i hvert tilfælde sammen med dem	Opbevaringsbegrænsning	cfg/check_lib.php; cfg/fristen_lib.php
Undersøgelse: offentliggørelse kun som sum, segmenter først fra 20 websteder med en formular, rådata slettes ved offentliggørelsen	R4 delvis, P3	cfg/studie_lib.php
Kontrolcontainere: eget isoleret netværk, ingen særlige rettigheder, skrivebeskyttede, hukommelses- og procesgrænser, tidsgrænse; filter mod private mål ved hver forespørgsel, service workers blokeret og WebSocket-forbindelser lukket, så intet omgår filteret; forespørgsler fra webserveren kun på webporte og kun til præcis den offentlige adresse, der er kontrolleret forinden	R13	scanner/src/worker.js; scanner/src/net.js
Aktiv kontrol for Kunder kun for et verificeret domæne (internt også for vores egne test- og demodomæner) og med nødstoppet slået til, kontrolleret to gange; højst fem indsendelser; kun tydeligt genkendte kontaktformularer uden obligatoriske personoplysninger; ingen domæner tilhørende offentlige myndigheder, uddannelsesinstitutioner, klinikker, lægepraksisser, politi eller domstole; sprogmodellen må ikke frigive noget; testbesked uden personoplysninger, markeret, med henvisning til crawlersiden og opt-out	R9	scanner/src/worker.js; scanner/src/classify.js; scanner/src/active.js
Browserforløb: kun GET og HEAD, farlige adresser spærret, opdigtede værdier forlader ikke browseren, billeder med sværtede inputfelter	R3 (for disse billeder), R9	scanner/src/browser.js
Filkontrol: kun verificerede domæner, én hentning pr. sti, højst 8 KB, indholdet gemmes aldrig	R9	cfg/dateien_lib.php
Anden sonde: slået fra som standard; ville kun modtage en fast liste over harmløse elementer, signeret	Modtagere	cfg/formular_probe_lib.php
Scanning bag login: kun verificeret domæne, betalt plan, ejer eller administrator, bekræftelse af »testkonto«; kryptering med scanserverens offentlige nøgle, bundet til domænet; adgangsoplysninger vises, logges og udleveres aldrig via API'et; overdragelse kun via standardinput; feltet i jobbet ryddes straks, rester efter én time; ingen skærmbilleder, ingen indsendelser, ingen logout- eller sletningsadresser, afbrydelse ved CAPTCHA; endelig sletning med overskrivning	R8	cfg/login_lib.php; scanner/src/login.js; scanner/src/geheim.js; scanner/src/worker.js
Leveringskontrol: slået fra som standard; hentningen læser kun headere og 8 KB uden læsemarkering; indhold og den besøgendes adresse aldrig i databasen; enhver hentet e-mail slettes, også dem, der ikke kan tildeles; tildelinger slettes efter 180 dage; bevis kun via kopien af netop denne test	R1, R2	cfg/zustellung_lib.php
Sværmbeskyttelse: kun domæner, IP-netværk slået fra; minimumstal; undtagelser for store tjenester og Kundedomæner; karantæne i stedet for sletning; listen genopbygges dagligt; rapporter slettes efter 30 dage	R11	cfg/swarm_lib.php
Sprogmodel på vores egen server, uden ret til at indsende	R10	scanner/src/classify.js
Signaler via Telegram indeholder kun en fast sætning uden variabler	Modtagere	cfg/check_lib.php
Ugentlig gendannelsestest af sikkerhedskopien med alarm ved fejl	Tilgængelighed	cfg/backup_lib.php; srv/cron_status.php

9.2 Delvis – på plads, men opfylder endnu ikke sit formål

Foranstaltning	Hvorfor den endnu ikke er fuldt virksom
»Rensede« skærmbilleder	Kun billederne fra browserforløb sværtes. Crawlerens billeder – forside og formularelementer – og billedet af svarsiden fra en aktiv kontrol gør ikke (R3).
Perioder for kontroldata	Virksomme for anonyme kontroller, kontroller af potentielle kunder og Kundekontroller; ikke for interne kontroller og ikke-offentliggjorte undersøgelser; uløste anomalinoter uden tidsbegrænsning (R4).
Sletning af kontrolkopierne	Virksom i vores visning af postkassen. Hvis kørslen afbrydes, bliver e-mails liggende; hvad postkasseudbyderen opbevarer i sine egne sikkerhedskopier, er ikke verificeret (R2).
Beskyttelse af adgangsoplysninger ved scanningen bag login	Stærk i hvile og i kontroltjenesten; ikke på vej til webstedet: http er tilladt, certifikatfejl ignoreres (R8).
Bevis for kontrol	Kontrolleres én gang og gælder derefter for altid; værtsnavnet på et domæne med bevis for kontrol kan dog ikke ændres, så beviset ikke overgår til en anden host (R7).
Oplysning til de registrerede	På plads for operatører via crawlersiden, identifikatoren, Privatlivspolitikken og opt-out; for besøgende ved leveringskontrollen afhængig af, at Kunden overtager tekstblokken; applikationen kontrollerer ikke dette.
Anmodning til Kunderne om ikke at lade særlige kategorier indgå i kontrolkopien	Anført i de juridiske dokumenter, men ikke understøttet teknisk: ved opsætningen spørger applikationen ikke om webstedets type og advarer ikke ved domæner, der ligner sundhed, jura eller uddannelse (R1).

9.3 Planlagt – ikke gennemført

Foranstaltning	Imødegår	Prioritet
Sletningsrute for interne kontroller: slet kontroller uden domæne og uden rapport efter en fast periode (forslag: 30 dage); slet en undersøgelses rådata senest en fast periode efter dens afslutning, også uden offentliggørelse (forslag: 90 dage); slet de eksisterende 85 kontroller med 369 billeder én gang	R4	Først
Aktivér først leveringskontrollen, når kontrakten med postkasseudbyderen er indgået, lagringssteder, underdatabehandlere og perioder for sikkerhedskopier er dokumenteret, overførselsmekanismen for postkasseudbyderen er afklaret, og MX-posterne for vores domæne peger direkte på postkassen; indtil da holdes funktionen spærret i produktionssystemet	R2	Først
Kontrollér sikkerheden ved hentningen fra postkassen på produktionssystemet, og dokumentér den, før leveringskontrollen aktiveres	R2	Først
Scanning bag login kun via https og med gyldigt certifikat; afvis http-adresser; certifikatfejl ved login som grund til afbrydelse	R8	Først
Gem ikke værdier i skjulte felter bag login (kun navn, type og længde) – allerede gennemført på denne måde, intet yderligere trin	R8	Udført
Begræns kontrolkopien til testbeskeder, hvor pluginet eller udvidelsen er i brug: bcc kun for indsendelser med vores testidentifikator	R1	Høj
Gem ikke afsenderdomænet for rigtige beskeder, og skriv det ikke i alarmer, hvis det hverken er webstedets domæne eller domænet for en kendt afsendelsestjeneste; i alarmen i stedet »fremmed afsenderdomæne«	R1	Høj
Advarsel ved opsætning af leveringskontrollen for domæner, der ligner sundhed, jura, sociale tjenester eller uddannelse, med henvisning til Kundens egen konsekvensanalyse	R1	Høj
Forny beviset for kontrol regelmæssigt (forslag: før hver aktiv kontrol verificeres det, om DNS-posten, metatagget, filen eller plugin-forbindelsen stadig findes; ellers fortsættes passivt, og Kunden underrettes)	R7	Høj
Ophør med at fotografere forsiden eller kun med sværtede billeder og ansigter; begræns formularbilleder til formularelementet (som i dag), og masker inputfelter som ved browserforløb	R3	Høj
Henvisning i grænsefladen for kontrollen af potentielle kunder: at sende det korte resultat uopfordret pr. e-mail eller telefon er direkte markedsføring, også mellem virksomheder, og kræver forudgående samtykke (Art. 398 i den polske lov om elektronisk kommunikation; i Tyskland § 7(2) UWG, dog er formodet samtykke tilstrækkeligt ved opkald til virksomheder)	R6	Høj
Infrastruktur: afslut hærdningen af serveradministrationen; krypteret kopi af sikkerhedskopien på en anden placering; krypter forbindelser i det interne netværk gennemgående; styrk adskillelsen mellem scanserveren og applikationen yderligere	R13	Høj
Periode for uløste anomalinoter (forslag: løsning inden for 30 dage, ellers sletning af IP-adressen)	R4	Middel
En side eller formular, hvorigennem nogen kan anmode om fjernelse af et domæne fra sværmbeskyttelsen	R11, R14	Middel
Før aktivering af IP-netværk i sværmbeskyttelsen: en ny version af denne vurdering	R11	Betingelse
Fastslå, om sprogmodelsoftwaren gemmer forespørgsler, og i så fald slå disse logge fra	R10	Lav

9.4 Procedurer og beslutninger, der endnu skal fastlægges

Ud over tekniske garantier kræver Art. 35(7)(d) også procedurer. Følgende udestår stadig:

• Brud på persondatasikkerheden. Opdagelse: indehaveren, applikationens fejlalarm, rapporter via kontaktpunktet for sårbarhedsrapporter eller contact@lukaswojcik.com. Beslutning om anmeldelse til UODO inden for 72 timer (Art. 33(1)): indehaveren. Underretning af berørte Kunder som dataansvarlige: uden unødig forsinkelse, om muligt inden for 48 timer, som lovet i Databehandleraftalen. Skal fastlægges: en skriftlig procedurebeskrivelse og en første øvelse; for leveringskontrollen desuden, hvordan det fastslås, hvilke Kunder der er berørt af et brud hos postkasseudbyderen.
• Brancher. Skal fastlægges: om leveringskontrollen tilbydes, tilbydes med en advarsel eller udelukkes for websteder inden for sundhed, jura, sociale tjenester og uddannelse.
• Interne kontroller. Skal fastlægges: hvad udbyderen bruger interne kontroller fra kommandolinjen til, hvem der må oprette dem, og hvor længe deres resultater bevares; samt om de ud over Fortegnelsen over behandlingsaktiviteter skal nævnes i Privatlivspolitikken.
• Undersøgelser. Skal fastlægges: hvem der sammenstiller lister, fra hvilke kilder, med hvilken maksimal størrelse, samt en kontrol før hver undersøgelse af, om den overholder forudsætningerne i denne vurdering.
• De registreredes synspunkter (Art. 35(9)). De er ikke indhentet til denne version. Art. 35(9) kræver kun, at de indhentes »hvor det er relevant«; efter vores vurdering er det i øjeblikket ikke tilfældet her. Operatører af kontrollerede websteder og besøgende på Kunders websteder har ingen egen kanal til os; at henvende sig målrettet til dem ville i sig selv være en ny behandling af deres data, og tjenesten er endnu ikke lanceret, så der endnu ikke findes nogen gruppe af faktiske registrerede. Deres interesser tages indirekte i betragtning: gennem robots.txt og opt-out, gennem de korte perioder og gennem det forhold, at indholdet af kontrolkopier ikke gemmes. Ved hver revision efter afsnit 12 overvejer vi på ny, om det er relevant at indhente deres synspunkter, f.eks. via feedback på crawlersiden eller fra Kunder, der bruger leveringskontrollen.

10. Restrisiko og forudgående høring efter Art. 36

Art. 36(1) kræver forudgående høring af tilsynsmyndigheden, hvis konsekvensanalysen viser, at behandlingen vil føre til høj risiko i mangel af foranstaltninger truffet af den dataansvarlige for at begrænse risikoen. Spørgsmålet er derfor ikke, om der blev identificeret høje risici – det blev der, fire – men om der er en høj risiko tilbage, når foranstaltningerne er på plads.

For de behandlingsaktiviteter, hvor formexposed er dataansvarlig (P1 til P4, P7), kan de høje risici R4 og R13 afhjælpes med almindelige midler: en sletningsrute og en oprydning i de eksisterende data, en krypteret sikkerhedskopi på en anden placering og hærdning af to servere. Med foranstaltningerne fra 9.3 falder de til lav til middel. R3, R5, R6 og R7 ligger på middel og falder til lav med de foreslåede foranstaltninger. Sværmbeskyttelse uden IP-netværk forbliver lav til middel. Forudgående høring er ikke påkrævet for denne del, hvis foranstaltningerne markeret »først« og »høj« gennemføres før lanceringen. Hvis en af disse foranstaltninger ikke er gennemført før lanceringen, er der en høj risiko tilbage for den pågældende behandlingsaktivitet. Denne behandlingsaktivitet startes så først, når foranstaltningen er gennemført, eller UODO høres først efter Art. 36(1).

For leveringskontrollen (P6) er situationen en anden af en grund, som ingen foranstaltning helt fjerner: hvad en besøgende skriver, er op til vedkommende. Med en indgået kontrakt, sikret hentning, begrænsning til testbeskeder, hvor det er muligt, og afkald på afsenderdomænet falder R2 til lav og R1 til middel. For Kunder, hvis besøgende typisk oplyser data efter Art. 9, kan R1 alligevel forblive høj. Pligten til høring ligger så hos Kunden som dataansvarlig, ikke hos formexposed. Vores anbefaling til sådanne Kunder er ikke at opsætte kontrolkopien for den generelle kontaktformular, men kun for formularer uden følsomt indhold, eller at undlade leveringskontrollen.

Restrisiko, ærligt opgjort. I dag ligger fire risici på højt med foranstaltningerne fra 9.1: R1 og R2 (leveringskontrol), R4 (kontroldata uden sletningsrute) og R13 (infrastruktur). Med foranstaltningerne fra 9.3 falder R2, R4 og R13 til lav til middel. R1 forbliver på middel og afhænger varigt af beslutninger, som Kunderne træffer. Ingen af de øvrige risici ligger over middel efter foranstaltningerne.

Art. 36 er ikke en sanktion, og en høring er ikke en indrømmelse. Det er den vej, forordningen stiller til rådighed for den situation, hvor en nyttig fremgangsmåde indebærer en risiko, som den dataansvarlige ikke fuldt ud har kontrol over. En Kunde, der vil bruge leveringskontrollen til beskeder med helbredsoplysninger, finder fakta til denne beslutning her.

11. Hvad Kunderne har brug for til deres egen konsekvensanalyse (Art. 28(3)(f))

For leveringskontrollen og scanningen bag login er Kunden dataansvarlig. Denne side giver Kunden beskrivelsen (afsnit 6.5 og 6.6), risiciene set fra vores side (R1, R2, R8) og status for foranstaltningerne (afsnit 9). Kun Kunden kan besvare følgende spørgsmål:

1. Hvad skriver mine besøgende? Må det forventes, at der via formularen kommer data om helbred, religion, oprindelse, fagforeningsmæssigt tilhørsforhold, seksuel orientering, strafbare forhold eller om børn? Så er en konsekvensanalyse for kontrolkopien som regel påkrævet, og kontrolkopien for denne formular bør genovervejes.
2. Har jeg brug for kontrolkopien for alle beskeder? For at bevise, at vores testbesked når frem, er det tilstrækkeligt med kopien af den. Hvor formularen tillader det, så sæt kun bcc for testbeskeder.
3. Hvordan informerer jeg mine besøgende? Databehandleraftalen kræver det; Tekst til privatlivspolitikken på dit websted beskriver kopiens vej og vores rolle.
4. Hvilket retsgrundlag har jeg? Vores tekstforslag nævner Art. 6(1)(f) (pålidelig modtagelse af henvendelser). For data efter Art. 9 er dette grundlag alene ikke tilstrækkeligt.
5. Hvilke alarmkanaler vælger jeg? Alarmer fra ægthedskontrollen kan nævne afsenderdomænet. Den, der sender alarmer til chattjenester uden for EU, overfører det dertil.
6. For scanningen bag login: Er testkontoen virkelig en testkonto med de mindst nødvendige rettigheder? Kan loginsiden kun nås via https? Ser testkontoen andre brugeres data? Hvis ja: på hvilke af de angivne sider?
7. Hvornår sletter jeg? Leveringskontrollen og testkontoen kan til enhver tid slås fra og slettes; testkontoen overskrives så permanent.

Yderligere dokumenter til Kundens vurdering: Databehandleraftalen, de tekniske og organisatoriske foranstaltninger, listen over underdatabehandlere og Fortegnelsen over behandlingsaktiviteter. Spørgsmål om enkelte forhold besvarer vi på contact@lukaswojcik.com.

12. Revision, version og godkendelse

Art. 35(11) kræver en revision for at vurdere, om behandlingen udføres i overensstemmelse med konsekvensanalysen, i hvert fald når der sker en ændring af risikoen. Vi reviderer denne vurdering mindst én gang om året og desuden før hver af følgende hændelser; hver af dem udløser en ny måling, ikke blot en gennemlæsning:

• start af produktionsdriften, med tal fra produktionssystemet i stedet for udviklingssystemet;
• første aktivering af leveringskontrollen på produktionssystemet og indgåelse af kontrakten med postkasseudbyderen;
• aktivering af IP-netværk i sværmbeskyttelsen;
• den første undersøgelse og enhver undersøgelse med en større liste end den foregående;
• aktivering af den anden sonde eller en ny modtager i kontrolforløbet;
• enhver ny brug af sprogmodellen, der går ud over klassificering af formularer og »Fix it for me«;
• enhver ændring af skærmbillederne, perioderne eller forudsætningerne for aktive kontroller.

Punkt	Oplysning
Dataansvarlig	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen · NIP 7252266190 · contact@lukaswojcik.com
Kompetent tilsynsmyndighed	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Polen
Databeskyttelsesrådgiver	Ikke udpeget; vurdering efter Art. 37 i afsnit 4
Faktuelt grundlag	Kildekoden til applikationen og kontroltjenesten, databaseskema, rækkeantal og indstillinger på udviklingssystemet, målt den 11. oktober 2026, kun læseadgang
Tilknyttede dokumenter	Privatlivspolitik, Databehandleraftale, Tekniske og organisatoriske foranstaltninger, Underdatabehandlere, Fortegnelse over behandlingsaktiviteter, EU's AI-forordning, Acceptabel brug og misbrug, FormExposedBot, Opt-out
Version	1.0 af 11. oktober 2026, første version
Revisioner efter Art. 35(11)	Endnu ingen (første version). Hver revision anføres her med dato, anledning og resultat.
Godkendelse	Endnu ikke godkendt. Godkendelse af indehaveren efter juridisk gennemgang og efter en beslutning om foranstaltningerne fra afsnit 9.3 og spørgsmålene fra afsnit 9.4. Der er indtil videre ikke indhentet ekstern databeskyttelsesrådgivning.

En afsluttende bemærkning hører hjemme i dokumentet og ikke i et følgebrev. De dele af formexposed, der når længst ind i andres domæner – testindsendelserne og login med andres adgangsoplysninger – er bygget med størst forsigtighed: to porte, hårde lofter, kryptering, der låser selv os ude. Risiciene i denne vurdering ligger for det meste et andet sted: i det, der følger med tilfældigt – rigtige beskeder i en bcc, personer på et skærmbillede, kontroller, som ingen længere sletter. Det er et gunstigt udgangspunkt, fordi det tilfældige kan stoppes uden at ændre tjenesten.