Vurdering av personvernkonsekvenser (personvernforordningen art. 35)

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

Versjon 1.1 · Sist oppdatert: 23. oktober 2026

1. Hva dette gjelder, og hva denne siden er

Denne siden er vurderingen av personvernkonsekvenser (DPIA) for formexposed etter personvernforordningen art. 35. Den besvarer først det innledende spørsmålet om en slik vurdering i det hele tatt kreves – for hver behandlingsoperasjon separat, ikke for tjenesten som helhet. Der svaret er ja, gjennomfører den vurderingen etter art. 35(7)(a) til (d): en systematisk beskrivelse, nødvendighet og forholdsmessighet, risikoene for de registrerte og tiltakene for å håndtere dem. Deretter følger gjenværende risiko, spørsmålet om forhåndsdrøfting etter art. 36 og reglene for gjennomgang.

Art. 35 krever ikke at en vurdering av personvernkonsekvenser publiseres. Vi publiserer den av to grunner. For det første trenger Kunder som bruker leveringskontrollen eller skanning bak innlogging, fakta som bare vi kjenner, til sin egen vurdering; vi skylder dem uansett disse faktaene som databehandler (personvernforordningen art. 28(3)(f)). For det andre kontrollerer crawleren vår nettsteder der operatørene ikke kjenner oss. De bør kunne lese hvilke risikoer vi ser for dem og personene på sidene deres, og hva vi gjør med dem.

Rettslig karakter. Denne vurderingen er dokumentasjon fra den behandlingsansvarlige etter personvernforordningen art. 35 som vi publiserer frivillig. Den er ikke en del av noen avtale og utgjør ingen tilsikring, garanti eller kvalitetsavtale overfor Kunder eller tredjeparter. Hvilke tjenester og beskyttelsestiltak vi er forpliktet til å levere Kundene, reguleres av Bruksvilkårene, Databehandleravtalen og vedleggene; for disse pliktene har de forrang fremfor denne siden. Siden beskriver stillingen på datoen for denne versjonen. Risikonivåer og vurderinger er vårt eget syn og foregriper ingen rettslig vurdering fra en tilsynsmyndighet eller domstol; tiltak beskrevet som «planlagt» er hensikter uten en forpliktende dato. For Kunder er siden et grunnlag for egen vurdering, ikke juridisk rådgivning.

Dette er den første versjonen av terskelvurderingen. Den undersøker behandlingsoperasjon for behandlingsoperasjon om en vurdering av personvernkonsekvenser kreves, og registrerer resultatet i punkt 3.5.

Hvert faktiske utsagn er underlagt samme prinsipp som i de øvrige juridiske dokumentene våre: målt, ikke planlagt. Det som er dokumentert i koden eller databasen, oppgis her med kildehenvisning. Det som ikke kunne dokumenteres, merkes «ikke verifisert». Det som bare er planlagt, kalles «planlagt». Vi navngir åpne spørsmål åpent sammen med det planlagte tiltaket; en vurdering som bare lister styrker, hjelper ikke menneskene den gjelder.

Begreper: En operatør er den som driver et kontrollert nettsted. En Kunde har en konto hos formexposed. En besøkende er den som bruker en Kundes nettsted, for eksempel kontaktskjemaet. En kildehenvisning betyr en fil, funksjon eller innstilling i kildekoden, målt mot utviklingssystemets tilstand 11. oktober 2026.

Vi trekker bevisst én grense for åpenheten: Åpne spørsmål om sikringen av våre egne servere beskrives bare i generelle vendinger (R13). Vi navngir risikoen og nivået, men ikke veien til en konkret sårbarhet; vi gir detaljene til en tilsynsmyndighet på forespørsel.

2. Roller: hvem som har plikten, og for hva

Art. 35 legger plikten på den behandlingsansvarlige. formexposed er behandlingsansvarlig for noen behandlingsoperasjoner, databehandler for Kundene for andre og ingen av delene for opplysningene som WordPress-tillegget og TYPO3-utvidelsen vår lagrer på en Kundes nettsted. Svaret på nesten alle spørsmål i dette dokumentet avhenger av hvilken rolle spørsmålet gjelder. Fordelingen følger Personvernerklæringen og Databehandleravtalen.

Behandlingsoperasjon	Rollen til formexposed	Hvem som har plikten etter art. 35
Kontroll av tredjepartsnettsteder uten instrukser fra operatøren: gratis kontroll, kontroll av potensielle kunder for byråer, studie	Behandlingsansvarlig	formexposed
Kontroll av domener i kundekontoen: overvåking, aktive testinnsendinger, nettleserforløp, tilgjengelige filer, skjemapuls	Behandlingsansvarlig for Kundens konto- og kontrolldata; databehandler for personopplysninger om tredjeparter som er synlige på Kundens verifiserte nettsted; så lenge et domene ikke er verifisert, behandlingsansvarlig som ved den gratis kontrollen	formexposed for sin egen del; Kunden for tredjepartsopplysninger på nettstedet sitt
Skanning bak innlogging med en testkonto	Databehandler: Innloggingsopplysningene og innholdet bak innloggingen tilhører Kundens nettsted	Kunden; formexposed bistår
Leveringskontroll med kontrollkopi	Databehandler	Kunden; formexposed bistår
Svermbeskyttelse: felles liste over lenkedomener fra blokkert spam	Behandlingsansvarlig: Vi kombinerer rapportene fra mange nettsteder, sammenstiller listen og distribuerer den	formexposed
Kundekontoer, innlogging, logger, kundestøtte, e-postsending, betalinger, dokumentasjonsregistreringer	Behandlingsansvarlig	formexposed
Kundeportal og månedsrapport til et byrås abonnenter	Databehandler	Byrået
Opplysninger som tillegget og utvidelsen lagrer på Kundens nettsted (karantene, sikkerhetsnett, lagrede henvendelser)	Ingen av delene: Opplysningene forlater aldri nettstedet	Nettstedets operatør

Dette gir et skille som vi oppgir uttrykkelig, fordi det ofte misforstås i begge retninger. Der formexposed er behandlingsansvarlig, gjennomfører vi vurderingen selv og bærer resultatet. Der vi er databehandler, kan vi ikke gjennomføre Kundens vurdering i Kundens sted, avgjøre spørsmålet om nødvendighet for Kunden eller forhåndsdrøfte med tilsynsmyndigheten etter art. 36 på Kundens vegne. Det vi kan og må gjøre der, er å levere alt Kunden trenger: beskrivelsen etter bokstav (a), de målte faktaene om risikoene etter bokstav (c) og en ærlig statusliste over tiltakene etter bokstav (d). For leveringskontrollen og skanning bak innlogging er denne siden nettopp dette.

En Kunde som overtar avsnittene om leveringskontrollen uendret som sin egen vurdering av personvernkonsekvenser, har ikke gjennomført en slik vurdering. Om kontrollkopien er berettiget for Kundens skjemaer, om særlige kategorier av personopplysninger kan forventes der, og hvordan de besøkende informeres, er spørsmål bare Kunden kan avgjøre. Punkt 11 oppsummerer det som må avklares til dette formålet.

3. Terskelvurdering: kreves en vurdering av personvernkonsekvenser?

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

Art. 35(1) krever en vurdering av personvernkonsekvenser der en type behandling, særlig ved bruk av ny teknologi, med hensyn til behandlingens art, omfang, sammenheng og formål sannsynligvis vil medføre høy risiko for fysiske personers rettigheter og friheter. Art. 35(3) navngir tre tilfeller der dette særlig gjelder. Ingen av de tre passer på formexposed, og dette bør begrunnes fremfor å hevdes:

Bokstav (a) – en systematisk og omfattende vurdering av personlige forhold knyttet til fysiske personer som bygger på automatisert behandling, og som avgjørelser med rettsvirkning eller tilsvarende betydelig påvirkning bygger på. Vi vurderer skjemaer og nettsteder, ikke personlige forhold hos mennesker. Tjenesten tar ingen avgjørelse med rettsvirkning for noen person. Det nærmeste er svermbeskyttelse: Meldinger med en lenke til et oppført domene havner i karantene på de tilkoblede nettstedene. Dette er en automatisk følge for meldingen, ikke en omfattende vurdering av en person; vi behandler det under kriteriet «Evaluering eller poengsetting» i punkt 3.3.
Bokstav (b) – behandling i stor skala av særlige kategorier etter art. 9 eller opplysninger om straffbare forhold etter art. 10. Ikke tilsiktet og ikke bygget. Slike opplysninger kan likevel nå oss via én vei: i kontrollkopien av reelle besøksmeldinger i leveringskontrollen. Dette avhenger av det enkelte tilfellet og er ikke behandling i stor skala etter denne bestemmelsen; det tas imidlertid hensyn til i risikovurderingen (R1).
Bokstav (c) – systematisk overvåking av et offentlig tilgjengelig område i stor skala. Dette betyr fysisk observasjon av steder, ikke henting av offentlige nettsider. Å bruke denne bestemmelsen som grunnlag for en nettstedscrawler ville være feil.

Den riktige veien er derfor art. 35(1) selv, anvendt gjennom de ni kriteriene i Artikkel 29-gruppens retningslinjer om vurdering av personvernkonsekvenser (WP248 rev.01, godkjent av Det europeiske personvernråd) og listen fra den polske tilsynsmyndigheten etter art. 35(4) (punkt 3.4).

3.2 De ni kriteriene i WP248-retningslinjene

Retningslinjene navngir ni egenskaper som tyder på sannsynlig høy risiko. Som tommelfingerregel vil en behandlingsoperasjon som oppfyller to av dem, i de fleste tilfeller kreve en vurdering av personvernkonsekvenser. En behandlingsansvarlig kan komme til en annen konklusjon i et enkelt tilfelle, men må da begrunne og dokumentere den. Omvendt kan ett enkelt kriterium være nok. På denne siden bruker vi følgende korte betegnelser:

C1 – Evaluering eller poengsetting, inkludert profilering og prediksjon, for eksempel av arbeidsprestasjoner, økonomisk situasjon, pålitelighet eller atferd.
C2 – Automatiserte avgjørelser med rettsvirkning eller tilsvarende betydelig virkning.
C3 – Systematisk monitorering, det vil si behandling som brukes til å observere, overvåke eller kontrollere registrerte, også gjennom nettverk. Retningslinjene begrunner uttrykkelig dette kriteriet med at registrerte ofte ikke vet hvem som samler inn opplysningene deres, og til hvilket formål.
C4 – Sensitive opplysninger eller opplysninger av svært personlig art: særlige kategorier etter art. 9 og 10, men også opplysninger der utlevering påvirker dagliglivet betydelig, inkludert elektronisk kommunikasjon som bør holdes konfidensiell.
C5 – Opplysninger behandlet i stor skala, målt etter antall registrerte, mengden og bredden av opplysninger, varigheten og den geografiske utstrekningen.
C6 – Sammenstilling eller kombinering av datasett som stammer fra ulike behandlingsoperasjoner eller ulike behandlingsansvarlige, på en måte de registrerte ikke ville forvente.
C7 – Opplysninger om sårbare registrerte, for eksempel ansatte, barn, pasienter eller andre personer i et skjevt maktforhold.
C8 – Innovativ bruk eller anvendelse av nye teknologiske eller organisatoriske løsninger; i tilsynspraksis behandles bruk av kunstig intelligens regelmessig som omfattet av dette kriteriet.
C9 – Behandling som hindrer registrerte i å utøve en rettighet eller bruke en tjeneste eller en avtale.

Vi vurderer hvert kriterium som «oppfylt», «grensetilfelle» eller «ikke oppfylt» og begrunner vurderingen ut fra koden. Et grensetilfelle teller ikke som oppfylt i summen, men nevnes i resultatet; der flere grensetilfeller peker i samme retning, tar vi behandlingsoperasjonen med i vurderingen.

3.3 Vurdering per behandlingsoperasjon

P1 – Gratis kontroll uten konto (kontroll av ethvert tredjepartsnettsted på forespørsel)

Alle kan skrive inn et domene på startsiden. Crawleren henter da høyst åtte offentlige sider fra nettstedet, leser skjemaene, tar skjermbilder og lager en rapport som alle med den tilfeldige lenken kan se. Nettstedoperatøren får ikke vite noe om dette med mindre vedkommende oppdager crawlerens identifikator i loggene sine.

C1 – grensetilfelle. Rapporten vurderer beskyttelsen av et skjema med et nivå («Ubeskyttet», «Delvis beskyttet», «Beskyttet») og en poengsum. For et aksjeselskap gjelder dette ikke en fysisk person. For enkeltpersonforetak og frilansere kan domenet knyttes til personen, og nivået sier da noe om aktsomheten i yrkesvirksomheten. Det som vurderes, er imidlertid et teknisk oppsett, ikke en persons atferd eller egenskaper. Vi behandler dette som et grensetilfelle.
C2 – ikke oppfylt. Ingenting avgjøres i forhold til operatøren. For personen som ber om kontrollen, gjelder grenser per IP-adresse og økt (cfg/check_lib.php); en avvist kontroll har ingen betydelig virkning.
C3 – ikke oppfylt. Det er en enkelt henting på forespørsel, høyst én gang per domene og uke (cfg/check_lib.php, innstillingen fc_domain_days = 7). Ingen mennesker observeres. Omstendigheten retningslinjene viser til som begrunnelse for C3 – at de registrerte ikke vet noe om behandlingen – foreligger imidlertid. Den tas med i risikovurderingen (R5).
C4 – ikke oppfylt. Det som lagres, er skjemastrukturen og funnene, ikke inntastede verdier (scanner/src/crawl.js lagrer bare lengden på en verdi for synlige felt). Skanneren leser begynnelsen av forhåndsutfylte skjulte felt (inntil 24 tegn) og dataattributter (inntil 60 tegn) bare under kontrollen for å oppdage tokener og tidsstempler; de lagres ikke. Skjermbilder kan tilfeldigvis vise personer og navn; nettstedet til en legepraksis viser spesialiteten i bildet. Dette er offentlige yrkesopplysninger, ikke helseopplysninger om en bestemt person.
C5 – grensetilfelle. Dagsgrensen er 200 godtatte kontroller (fc_daily_cap), altså matematisk inntil omtrent 73 000 nettsteder i året. Bare noen få personopplysninger oppstår per nettsted, og varigheten er kort (30 dager). Målt på utviklingssystemet finnes 2 anonyme kontroller i datasettet. Ikke oppfylt i dag; grensetilfelle med den utformede kapasiteten.
C6 – ikke oppfylt. I tillegg til å hente sidene forespør tjenesten domenets alder via RDAP-tjenesten rdap.org (bare domenenavnet overføres; bare registreringsdatoen lagres, mellomlagret) og foretar DNS-oppslag. Dette er tekniske opplysninger om domenet, ikke en kombinasjon av datasett om mennesker.
C7 – ikke oppfylt.
C8 – oppfylt, i svak form. En automatisert nettleser kontrollerer sidene, og en språkmodell på vår egen server klassifiserer skjemaer reglene ikke gjenkjenner (scanner/src/classify.js). Modellen ser sidetittel, adresse, feltetiketter og inntil 400 tegn skjematekst. Den kan aldri gjøre et skjema «mulig å sende inn».
C9 – ikke oppfylt.

Foreløpig resultat P1: Ett kriterium i svak form (C8), to grensetilfeller (C1, C5). Ingen plikt etter tommelfingerregelen. Fordi begge grensetilfellene peker i samme retning og de registrerte ikke vet noe om behandlingen, tar vi P1 med i vurderingen.

P2 – Kontroll av potensielle kunder for byråer

Et byrå med Business-abonnement og egen merkevare satt opp kan få nettstedet til en potensiell kunde kontrollert passivt. Det mottar et kort funn under egen merkevare og en detaljert rapport og videreformidler lenken selv (cfg/akquise_lib.php). Vi kontakter ingen.

C1 – grensetilfelle, sterkere enn for P1. Det korte funnet er uttrykkelig ment som en «døråpner til den første samtalen». Vurderingen av nettstedet blir dermed grunnlag for en kommersiell henvendelse til en person.
C5 – ikke oppfylt. Høyst 30 kontroller per byrå og måned (prospect_monthly), slettes etter 90 dager.
C8 – oppfylt, i svak form (samme teknologi som P1).
Øvrige kriterier – ikke oppfylt. Funnet presenteres med byråets merkevare, men knyttes ikke til andre opplysninger om operatøren.

Foreløpig resultat P2: Ingen plikt etter tommelfingerregelen; tas med av samme grunner som P1 og fordi formålet – kundeverving – innebærer en egen risiko (R6).

P3 – Studien «Skjemasikkerhetsindeks»

For en studie kontrolleres en liste over nettsteder passivt, begrenset til høyst fem åpne jobber per kjøring av statusprosessen, som kjører hvert femte minutt (cfg/studie_lib.php). Bare samlede tall publiseres, og segmenter bare fra 20 nettsteder med et skjema (study_min_segment, cfg/studie_lib.php). Rådata slettes ved publisering (cfg/studie_lib.php).

C5 – grensetilfelle, oppfylt for store lister. Listens størrelse er ikke begrenset i koden; frekvensbegrensningen tillater matematisk mer enn tusen kontroller om dagen. En studie av et nasjonalt marked omfatter tusenvis av nettsteder, mange drevet av enkeltpersonforetak. Fra en slik størrelse anser vi kriteriet som oppfylt.
C8 – oppfylt, i svak form.
C1 – ikke oppfylt. Selv om det enkelte nettstedet vurderes, publiseres bare totalsummen; vurderingen tjener ikke til å uttale seg om den enkelte operatøren.
Øvrige kriterier – ikke oppfylt.

Foreløpig resultat P3: For studier av den utformede størrelsen to kriterier (C5, C8). Studien når dermed terskelen; formexposed gjennomfører vurderingen som behandlingsansvarlig. Målt på utviklingssystemet er ingen studie opprettet så langt.

P4 – Kontroll av domener i kundekontoen

Kunden får domenene i kontoen kontrollert regelmessig. Når Kunden har dokumentert retten til å kontrollere domenet, kommer aktive testinnsendinger (høyst fem per kontroll), søk etter tilgjengelige filer og konfigurerte nettleserforløp i tillegg.

C3 – ikke oppfylt. Kontrollen er planlagt og gjentatt, men gjelder Kundens eget nettsted og utføres på Kundens anmodning, ikke for å observere mennesker.
C4 – grensetilfelle, nei. Søket etter tilgjengelige filer leser høyst de første 8 KB fra stier som /backup.sql eller en feilsøkingslogg for å avgjøre ut fra innholdet om filen virkelig er tilgjengelig (cfg/dateien_lib.php). Et slikt utdrag kan inneholde skjemainntastinger fra besøkende. Det kontrolleres bare i minnet og lagres aldri; det som lagres, er sti, type og alvorlighetsgrad.
C8 – oppfylt, i svak form.
Øvrige kriterier – ikke oppfylt.

Tilføyd tiltaksplantrinn. Kvalifiserte betalte rapporter kan inneholde lokalt generert rådgivende tekst basert på utvalgte funn og skannemetadata. Den lagres med kontrollen og vises med en KI-merknad; enkeltfunnene er fortsatt avgjørende. Den endrer ikke nettsteder automatisk og tar ikke avgjørelser om mennesker med rettslig eller tilsvarende betydelig virkning. Bruk av en språkmodell alene avgjør ikke om en separat vurdering av personvernkonsekvenser kreves. Inndata, mottakere, omfang og gjenværende risikoer må vurderes sammen med den underliggende kontrollen, inkludert mulig gjentakelse av personopplysninger fra URL-er eller merknader og uriktige anbefalinger i en rapport som kan deles via lenke. Punkt 7 til 9 nedenfor omfatter dette trinnet; dette faktiske tillegget hevder ikke at produksjonsmåling, eiergodkjenning eller en ny vurdering av gjenværende risiko er fullført.

Foreløpig resultat P4: Den underliggende tekniske kontrollen når ikke terskelen ut fra faktaene beskrevet ovenfor. Det tilføyde lokale rådgivningstrinnet etablerer ikke i seg selv en separat plikt, men det tidligere terskelresultatet erstatter ikke vurderingen av de faktiske inndataene, omfanget, mottakerne og virkningene. Tas med fordi de aktive testinnsendingene og filkontrollen avhenger av dokumentasjon som aldri fornyes (R7).

P5 – Skanning bak innlogging

For et verifisert domene kan Kunden lagre en testkonto for nettstedet sitt. Skanneren logger inn med den og leser skjemaene på inntil fem angitte sider i medlemsområdet (cfg/login_lib.php, scanner/src/login.js).

C4 – grensetilfelle. Innloggingsopplysninger er ikke opplysninger av svært personlig art etter retningslinjene, men misbruk av dem åpner medlemsområdet. Avhengig av nettstedet kan konfidensielt innhold ligge bak en innlogging, for eksempel i en medlems- eller pasientportal. Dette avhenger av Kunden, ikke av oss.
C8 – ikke oppfylt. Automatiserte innlogginger er vanlige i overvåkingstjenester.
Øvrige kriterier – ikke oppfylt.

Foreløpig resultat P5: Ingen plikt etter tommelfingerregelen. For Kunder der medlemsområdet viser konfidensielt innhold, kan dette endre seg; avgjørelsen ligger da hos dem. Tas med på grunn av sikkerhetsrisikoene (R8).

P6 – Leveringskontroll med kontrollkopi

Kunden legger inn en kontrolladresse fra formexposed som blindkopi i skjemaets e-postinnstillinger. Dermed går hver skjema-e-post også til kontrollpostkassen vår – testmeldingen vår så vel som hver reelle melding fra en besøkende. En automatisert henting leser hodene og de første 8 KB, tilordner e-posten, vurderer SPF, DKIM og DMARC og sletter den (cfg/zustellung_lib.php).

C4 – oppfylt. Det besøkende skriver i et kontaktskjema, er elektronisk kommunikasjon til en virksomhet med vilkårlig innhold. På nettstedet til en legepraksis, et advokatfirma, en rådgivningstjeneste eller en skole må opplysninger etter art. 9 eller om barn forventes. Retningslinjene nevner uttrykkelig konfidensiell elektronisk kommunikasjon under dette kriteriet.
C3 – grensetilfelle, snarere oppfylt. Hver melding kopieres planmessig og kontinuerlig og vurderes automatisk uten at avsenderen merker det. Formålet er å kontrollere e-postveien, ikke å observere mennesker. Omstendigheten retningslinjene begrunner kriteriet med – at registrerte ikke vet hvem som mottar opplysningene deres – foreligger imidlertid fullt ut så lenge Kunden ikke informerer de besøkende.
C7 – avhengig av Kunden. Pasienter, advokatklienter, jobbsøkere, foreldre og elever står ofte i et avhengighetsforhold til mottakeren av meldingen.
C5 – grensetilfelle, nei. Ikke i stor skala for den enkelte Kunden. Hos formexposed samles kopiene fra mange Kunder i én postkasse; dette øker tyngden av et brudd, ikke antallet per behandlingsansvarlig.
Øvrige kriterier – ikke oppfylt. Tilordningen til domene og test er ikke sammenstilling av datasett om mennesker; teknologien er ikke ny.

Foreløpig resultat P6: C4 oppfylt, C3 grensetilfelle og snarere oppfylt, C7 oppfylt for mange typiske Kunder. I den typiske situasjonen er dermed to eller flere kriterier oppfylt. En vurdering av personvernkonsekvenser kreves – som en plikt for Kunden, som er behandlingsansvarlig. Punkt 6 til 11 gir Kunden faktaene til dette.

P7 – Svermbeskyttelse

Tilkoblede WordPress-nettsteder rapporterer én gang om dagen domenene til lenker fra meldinger som beskyttelseslaget har stoppet. Et domene som vises på minst tre ulike nettsteder med minst fem treff innen sju dager, settes på en felles liste; listen sendes tilbake til alle tilkoblede nettsteder, som deretter setter meldinger med lenker til dette domenet i karantene (cfg/swarm_lib.php).

C6 – oppfylt. Rapporter fra mange innbyrdes uavhengige nettsteder, altså ulike behandlingsansvarlige, kombineres og returneres til alle som en felles liste.
C1 – oppfylt i den utstrekning et domene kan knyttes til en fysisk person. Listen er en klassifisering som spamkilde. Retningslinjene nevner kontroll mot en felles svindeldatabase som eksempel på dette kriteriet. De fleste domenene på en slik liste tilhører virksomheter eller er engangsdomener; en persons domene kan imidlertid havne på den, med rette eller gjennom bevisst plantede falske rapporter.
C9 – grensetilfelle. En melding med en oppført lenke når ikke mottakeren umiddelbart, men ligger i karantene frem til den frigis. Den går ikke tapt.
C2 – ikke oppfylt. Karantenen er en automatisert følge for en melding, uten rettsvirkning og med menneskelig frigivelse fra mottakeren.
Øvrige kriterier – ikke oppfylt. IP-nettverk er slått av (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Foreløpig resultat P7: To kriterier (C6, C1) og ett grensetilfelle (C9). Terskelen er nådd; formexposed gjennomfører vurderingen som behandlingsansvarlig. Med IP-nettverk slått på ville C1 og C6 være oppfylt uten forbehold; aktivering krever en ny versjon av denne vurderingen (punkt 12). Målt på utviklingssystemet finnes verken rapporter eller listeoppføringer.

P8 – Kundekontoer, innlogging, logger, kundestøtte, e-post, betalinger

C1 og C9 – ikke oppfylt. Påfallende atferd i den gratis kontrollen fører til en merknad med IP-adressen (cfg/check_lib.php) og eventuelt avvisning av videre kontroller. Dette er forebygging av misbruk med liten virkning, ikke evaluering av personlige forhold.
Øvrige kriterier – ikke oppfylt. Dette er de vanlige opplysningene i en tjeneste for næringsdrivende.

Foreløpig resultat P8: Ingen vurdering av personvernkonsekvenser kreves. Behandlingsoperasjonene beskrives i Protokoll over behandlingsaktiviteter.

P9 – Tilleggstall, feltfeil, opptaker, merke, kundeportal, «Fix it for me»

Tillegget og utvidelsen overfører daglige tall, oversikten over tillegg og feilkategorier, og WordPress-tillegget overfører i tillegg lenkedomener for svermbeskyttelse (på som standard) (P7), intet innhold, ingen adresser, navn eller IP-adresser til besøkende; opptakeren oppbevarer selektorer i høyst 15 minutter i administratorens nettleser. Ingen kriterier oppfylt.
Når merket lastes, overføres vanlige tilkoblingsopplysninger til nettserverloggen, uten informasjonskapsel. Ingen kriterier oppfylt.
Kundeportalen behandler abonnentenes e-postadresser med dobbel bekreftelse på vegne av byrået. Ingen kriterier oppfylt.
«Fix it for me» får innlimt skjemakode skrevet om av en språkmodell på vår egen server; koden lagres ikke. C8 i svak form, intet annet.

Foreløpig resultat P9: Ingen vurdering av personvernkonsekvenser kreves.

3.4 Listen fra den polske tilsynsmyndigheten etter art. 35(4)

Ansvarlig myndighet er lederen for det polske personvernkontoret (Prezes Urzędu Ochrony Danych Osobowych, UODO). Lederen publiserte listen over typer behandlingsoperasjoner som krever en vurdering av personvernkonsekvenser, i kunngjøringen av 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, punkt 666). Listen knytter oppføringene til kriteriene i WP248-retningslinjene, gir eksempler og er uttrykkelig ikke uttømmende; den erstatter ikke vurderingen etter art. 35(1).

Etter vår lesning svarer følgende behandlingstyper i listen i sitt innhold til behandlingsoperasjoner hos formexposed:

Behandlingstype etter listen (omskrevet)	Tilordnet kriterium	Behandlingsoperasjon hos formexposed	Vurdering
Sammenligning, evaluering eller utledning basert på analyse av opplysninger fra ulike kilder	C6	P7 Svermbeskyttelse	gjelder
Evaluering eller poengsetting, inkludert profilering	C1	P7 Svermbeskyttelse; P1 og P2 som grensetilfeller	gjelder P7
Behandling av særlige kategorier av personopplysninger	C4	P6 Leveringskontroll	gjelder avhengig av Kunden
Innovativ bruk eller anvendelse av teknologiske løsninger	C8	P1 til P4 (språkmodell for klassifisering)	gjelder i svak form
Behandling i stor skala	C5	P3 Studie	gjelder store lister
Systematisk overvåking av offentlig tilgjengelige steder, inkludert med gjenkjenning av egenskaper	C3	–	gjelder ikke: det menes steder, ikke nettsteder

Denne tilordningen er en lesning, ikke et sitat; ordlyden i oppføringene skal kontrolleres mot den i den juridiske gjennomgangen. Den bekrefter resultatet i punkt 3.3, men endrer det ikke. Så vidt vi vet har UODO ikke publisert noen liste etter art. 35(5) – behandlingsoperasjoner der ingen vurdering av personvernkonsekvenser kreves.

3.5 Resultat av terskelvurderingen

Behandlingsoperasjon	Oppfylt	Grensetilfelle	Resultat
P1 Gratis kontroll	C8 (svak)	C1, C5	ikke obligatorisk; tatt med
P2 Kontroll av potensielle kunder	C8 (svak)	C1	ikke obligatorisk; tatt med
P3 Studie	C8 (svak), C5 for store lister	–	kreves (plikt for formexposed)
P4 Kontroll av Kundens domener	C8 (svak)	C4 (filkontroll)	ikke obligatorisk; tatt med
P5 Skanning bak innlogging	–	C4	ikke obligatorisk; tatt med; for Kunden avhengig av innhold
P6 Leveringskontroll	C4; C7 avhengig av Kunden	C3 (snarere oppfylt), C5	kreves (plikt for Kunden; denne siden bistår etter art. 28(3)(f))
P7 Svermbeskyttelse	C6, C1	C9	kreves (plikt for formexposed)
P8 Kontoer, logger, kundestøtte, betalinger	–	–	kreves ikke
P9 Tilleggstall, merke, portal, «Fix it for me»	C8 (svak, bare «Fix it for me»)	–	kreves ikke

Resultat etter art. 35(1): En vurdering av personvernkonsekvenser kreves for enkelte behandlingsoperasjoner hos formexposed. Den kreves for svermbeskyttelse og studier av den utformede størrelsen, og formexposed gjennomfører den som behandlingsansvarlig. For leveringskontrollen kreves den i den typiske situasjonen, men som en plikt for Kunden; formexposed gir grunnlaget. For de øvrige kontrollene av tredjepartsnettsteder og egne nettsteder er den ikke obligatorisk. Vi tar dem likevel med fordi de bruker samme teknologi, fordi flere grensetilfeller peker i samme retning og fordi de registrerte – operatører uten konto og personer på kontrollerte sider – ikke vet noe om behandlingen. Ingen vurdering kreves for kontoer, logger, kundestøtte og betalinger.

Punkt 6 til 10 gjelder derfor P1 til P7. Der et utsagn bare gjelder én av disse behandlingsoperasjonene, er det merket slik.

4. Personvernombud: vurderingen etter art. 37

Intet personvernombud er utpekt. Art. 37(1) binder både behandlingsansvarlig og databehandler; spørsmålet er derfor vårt eget. De tre lovbestemte tilfellene:

Art. 37(1)	Vilkår	Resultat
bokstav (a)	Offentlig myndighet eller organ	Ikke relevant; LW IT Solutions Company Lukas Wójcik er et privat enkeltpersonforetak.
bokstav (b)	Kjernevirksomheten består av behandlingsoperasjoner som krever regelmessig og systematisk monitorering av registrerte i stor skala	Kjernevirksomheten er kontroll og overvåking av nettsteder og skjemaer, regelmessig og systematisk. Ingen mennesker overvåkes imidlertid: Crawleren observerer ikke atferd, og leveringskontrollen vurderer e-poster bare for levering og autentisitet. Ikke oppfylt.
bokstav (c)	Kjernevirksomheten består av behandling i stor skala av opplysninger etter art. 9 eller 10	Ikke tilsiktet. Særlige kategorier kan nå oss gjennom kontrollkopien i leveringskontrollen; dette er tilfeldig, ikke kjernevirksomhet. Ikke oppfylt.

Etter vår vurdering foreligger derfor ingen plikt til å utpeke et. Om polsk rett krever utpeking ut over dette etter art. 37(4), er et åpent spørsmål for den juridiske gjennomgangen. Siden intet personvernombud er utpekt, er rådføringen etter art. 35(2) ikke relevant. Hvis den juridiske gjennomgangen finner at utpeking er påkrevd, innhentes råd fra personvernombudet som da utpekes, før denne vurderingen godkjennes (punkt 12). Kontaktperson for spørsmål om vurderingen er eieren på contact@lukaswojcik.com.

5. Metode, kilder og grenser for denne versjonen

Faktaene i dette dokumentet kommer fra kildekoden til applikasjonen og skanneren, fra databaseskjemaet og fra radantall og innstillinger på utviklingssystemet, målt 11. oktober 2026. Databasen og serverne ble åpnet med bare lesetilgang. Der en måling motsier en hensikt – også et utsagn i våre egne rettstekster – rapporterer vi målingen. Vi anvender ikke godkjente atferdsnormer etter art. 40 der etterlevelse måtte tas med i vurderingen etter art. 35(8).

Utviklingssystemet ble målt. Tjenesten er ennå ikke lansert. Tallene er derfor små og delvis testartefakter: 112 kontroller, 110 av dem uten et Kundedomene; 432 skjermbilder; 2 domener, 1 av dem verifisert; ingen leveringskontroll slått på; ingen testkonto lagret for skanning bak innlogging; ingen studie; ingen rapporter i svermbeskyttelsen. Målinger skal gjentas før lansering og med regelmessige intervaller etterpå.
Ikke målt i denne versjonen og må tilføyes før godkjenning er: konfigurasjonen av produksjonssystemet, inkludert om og hvordan kontrollpostkassen er satt opp og om nøkkelparet for skanning bak innlogging er satt opp der; om språkmodellprogramvaren logger forespørsler; tilstanden til serveradministrasjonen (R13); avtalen med e-postleverandøren.
Det kunne ikke måles hvor mange reelle besøksmeldinger som vil passere gjennom kontrollkopien, og hvilke sektorer Kundene vil komme fra. Begge deler bestemmer tyngden av R1 og R2 og skal fastslås etter lansering.
Kildehenvisningene peker til filer og funksjoner i utviklingssystemets kildekode. Det avgjørende er den beskrevne funksjonen, ikke plasseringen i filen.

Dette dokumentet er et utkast. Det er ennå ikke godkjent av den behandlingsansvarlige (avsnitt 12), og to av konklusjonene – vurderingen av omfanget for P1 og P3 og vekten av leveringskontrollen – avhenger av tall som først vil foreligge etter lansering.

6. (a) Systematisk beskrivelse av behandlingsaktivitetene og formålene

6.1 Hvordan kontrollsystemet er bygget opp

formexposed kjører på egne servere i Polen, uten en ekstern vertsleverandør: en webserver med applikasjonen og databasen, og en skanneserver med kontrolltjenesten og en lokal språkmodell, begge i samme interne nettverk. En kontroll foregår slik:

Applikasjonen oppretter en jobb i databasen – underlagt grensene og sperrene som er angitt i avsnitt 6.3.
Kontrolltjenesten på skanneserveren henter jobben, kontrollerer sperrelisten, vertsnavnene og, ved anonyme kontroller, domenets alder på nytt, og starter en isolert container for akkurat denne jobben: eget nettverk med egne filterregler, ingen særlige rettigheter, et skrivebeskyttet filsystem, minne- og prosessgrenser og en tidsgrense (scanner/src/worker.js).
Inne i containeren henter en automatisert nettleser høyst åtte offentlige sider, først startsiden, deretter helst sider med kontaktinformasjon, leverandøropplysninger og brukerstøtte. Først leser den robots.txt; en utestenging av FormExposedBot eller av alle søkeroboter som omfatter startsiden, avslutter kontrollen, og det samme gjelder hvis robots.txt ikke kan nås eller det oppstår en serverfeil ved henting (scanner/src/net.js). Forbud for enkelte understier overholdes ikke særskilt. Skjemapuls, henting av dokumentasjon, verktøyet for HTTP-hoder og søket etter eksponerte filer leser ikke robots.txt. I tillegg til de åtte sidene kommer opptil tre sider med et klikk på «Avvis» i informasjonskapselbanneret, opptil tre sider i mobilvisning, aktive tester for bekreftede domener og opptil fem sider bak en innlogging; sidene lastes etter hverandre, ikke parallelt. Hver forespørsel fra nettleseren – også omdirigeringer og innebygd innhold – går gjennom et filter som avviser private nettverk og andre porter.
Containeren skriver et resultat og skjermbildene til en midlertidig mappe. Kontrolltjenesten sender resultatet og bildene til applikasjonen over det interne nettverket og sletter den midlertidige mappen, også etter en feil (scanner/src/worker.js).
Applikasjonen behandler resultatet, sammenligner det med forrige kontroll for Kundens domener og melder endringer til mottaksstedene Kunden har konfigurert.

6.2 Hva søkeroboten lagrer – og hva den ikke lagrer

Element	Hva som lagres	Hva som ikke lagres	Kildehenvisning
Sider	Adresse, HTTP-status, HTTP-hoder, Content Security Policy, tredjepartsverter som forespørres (høyst 120)	Sideinnhold som tekst eller HTML	`scanner/src/crawl.js`
Skjemafelt	Type, navn, etikett, plassholder, obligatorisk felt, synlighet, lengden på en eksisterende verdi	Feltverdier; for skjulte felt leses de første 24 tegnene i verdien bare under kontrollen (for å oppdage tokener)	`scanner/src/crawl.js`
Mottakeradresser i skjemaet	bare domenet	adressen	`scanner/src/crawl.js`
Skript	Oversikt med kontrollsum; adresser og innledende tekst uten kontoidentifikatorer fra reklame- og analysetjenester	Konto- og pikselidentifikatorer	`scanner/src/crawl.js`
Medlesere	hvilke reklamepiksler og opptaksverktøy som lastes før og etter at «Avvis» klikkes i informasjonskapselbanneret, og om de maskerer inndata	Identifikatorer for kontoene hos disse tjenestene	`scanner/src/mitleser.js`, `scanner/src/einwilligung.js`
Skjematekst	opptil 400 tegn sendes til den lokale språkmodellen hvis reglene ikke gjenkjenner typen	Utlevering til tredjeparter; lagring av teksten	`scanner/src/classify.js`
Skjermbilder (søkerobot)	synlig område på den første siden; for hvert synlige skjema et bilde av skjemaelementet	–	`scanner/src/crawl.js`
Skjermbilder (aktiv kontroll)	Bilde av svarsiden etter testinnsendingen; i tillegg status, måladresse, tittel og de første 300 tegnene i teksten	–	`scanner/src/active.js`
Skjermbilder (nettleserforløp)	Bilde av skjemaet med svarte felt over inndatafeltene, komprimert, høyst 32 KB	Inndata	`scanner/src/browser.js`
Bak innloggingen	som for skjemafelt ovenfor	Skjermbilder, informasjonskapsler, lenker	`scanner/src/login.js`

Disse elementene inneholder ikke personopplysninger som et tilsiktet ledd i utformingen, men de kan gjøre det tilfeldig: navnet på en kontaktperson ved siden av skjemaet, et teambilde på startsiden, et telefonnummer i en etikett, e-postdomenet til en enkeltperson, et navn i en plassholder. Bak innloggingen kommer opplysninger om testkontoen og, avhengig av nettstedet, om andre brukere i tillegg.

6.3 Hvem som utløser en kontroll, og hva som da gjelder

Utløser	Tillitsnivå i jobben	Testinnsendinger	Resultatet er tilgjengelig via	Sletting
Noen skriver inn et domene på startsiden (gratis kontroll)	anonymous	nei	Rapport under en tilfeldig lenke	30 dager, inkludert bilder (`cfg/check_lib.php`)
Programtillegg eller utvidelse uten konto	plugin	nei	Rapport under en tilfeldig lenke	30 dager
Byrå for en potensiell kunde	registered	nei	Kort funn og rapport under en tilfeldig lenke	90 dager (`cfg/akquise_lib.php`)
Kunde, domene uten dokumentasjon	registered	nei	Konto; rapport under en tilfeldig lenke	13 måneder, den siste kontrollen beholdes
Kunde, domene med dokumentasjon	verified	ja, høyst fem per kontroll	Konto; rapport under en tilfeldig lenke	13 måneder, den siste kontrollen beholdes (`cfg/fristen_lib.php`)
Studie	internal	nei	bare samlede tall etter publisering	ved publisering; uten publisering ingen tidsgrense (R4)
Intern kontroll fra kommandolinjen hos leverandøren	internal; for våre egne test- og demodomener også «verified»	nei; med nivået «verified» ja (bare våre egne test- og demodomener)	bare internt	ingen tidsgrense (R4)

Flere lag ligger foran den gratis kontrollen (cfg/check_lib.php): en nødstopp; reCAPTCHA; det samme domenet høyst én gang i løpet av sju dager (deretter vises den eksisterende rapporten); grenser per IP-adresse, per økt (som en hashverdi, aldri selve øktidentifikatoren) og for hele tjenesten per dag; sperrelisten fra opt-out og robots.txt; kontrollen av at domenet peker til offentlige adresser; og en sperre for svært nye eller ukjente domener. Avvik – mange forskjellige domener fra én IP-adresse, mange forespørsler på kort tid – registreres med IP-adressen og utløser et signal uten innhold (cfg/check_lib.php).

6.4 Kontroll av domener i Kundens konto

Kunden dokumenterer at den har rett til å råde over et domene: med DNS-oppføring, metatagg, fil eller via vårt programtillegg (cfg/verify_lib.php). Først da behandles domenet som bekreftet. Planleggeren for overvåking planlegger regelmessige kontroller bare for aktive, overvåkede og bekreftede domener (cfg/monitor_lib.php).

Aktive testinnsendinger er underlagt to sperrer: applikasjonen aktiverer aktiv modus for Kunder bare for bekreftede domener (for våre egne test- og demodomener kan leverandøren opprette en kontroll med nivået «verified» via et internt kommandolinjeverktøy), og kontrolltjenesten kontrollerer tillitsnivået og nødstoppen fc_active_enabled på nytt (scanner/src/worker.js). Bare et skjema som reglene med høy sikkerhet gjenkjenner som et generelt kontaktskjema, som ikke har obligatoriske felt for reelle personopplysninger, og hvis domene ikke ser ut som en offentlig myndighet, utdanningsinstitusjon, klinikk, legepraksis, politi eller domstol, kan sendes inn (scanner/src/classify.js). Språkmodellen kan ikke gjøre et skjema mulig å sende inn (scanner/src/classify.js). Høyst fem innsendinger sendes per kontroll (fc_active_max_posts), tydelig merket, med avsenderen dummy@formexposed.com, en adresse under .invalid for å teste e-postvalidering og en ufarlig ekstra hodelinje for å oppdage injeksjon i e-posthoder (scanner/src/active.js).
Nettleserforløp kontrollerer konfigurerte skjemaforløp i en nettleser frem til punktet rett før innsending. Bare GET- og HEAD-forespørsler er tillatt; alt annet avbrytes, og det samme gjelder adresser som inneholder ord for utlogging, sletting, kjøp eller betaling (scanner/src/browser.js). Under kontrollen fylles obligatoriske felt med oppdiktede verdier som aldri forlater nettleseren.
Eksponerte filer søkes etter ukentlig, bare for bekreftede domener, med høyst én henting per sti, høyst 8 KB og uten at innhold noen gang lagres (cfg/dateien_lib.php).
En uavhengig andre test er klargjort og er slått av som standard (browser_probe_enabled = 0). Hvis den ble slått på, ville den bare motta domenet, adressen, selektoren, trinnene og nettleservalget, aldri påloggingsopplysninger, skjermbilder eller besøksdata (cfg/formular_probe_lib.php).

6.5 Skanning bak innloggingen

Forutsetninger: funksjonen er konfigurert, domenet er bekreftet, og Kunden har et betalt abonnement og er eier eller administrator av arbeidsområdet (cfg/login_lib.php); Kunden bekrefter at kontoen er en testkonto med færrest mulig rettigheter (cfg/login_lib.php).

Brukernavnet og passordet krypteres umiddelbart på webserveren med skanneserverens offentlige nøkkel: en engangsnøkkel per post (X25519), nøkkelavledning (HKDF-SHA256), AES-256-GCM, bundet til domenet (cfg/login_lib.php). Bare kontrolltjenesten på skanneserveren har den private nøkkelen (scanner/src/geheim.js). Den som har webserveren, databasen eller en sikkerhetskopi, har bare kryptert tekst.
Grensesnittet viser bare det første tegnet og lengden på brukernavnet (cfg/login_lib.php). Påloggingsopplysninger vises aldri, loggføres aldri og utleveres aldri via API-et.
For en kontroll legger applikasjonen den krypterte teksten ved jobben. Kontrolltjenesten dekrypterer den, tømmer umiddelbart feltet i jobben og sender påloggingsopplysningene til containeren bare via standard inndata, aldri som kommandolinjeargumenter (scanner/src/worker.js). Rester i avbrutte jobber fjernes av statusprosessen etter én time (cfg/login_lib.php).
Inne i containeren logger nettleseren inn. Den avbryter hvis innloggingssiden omdirigerer til en annen vert, hvis innloggingsskjemaet har en CAPTCHA (vi omgår ikke CAPTCHA-er), eller hvis et passordfelt fortsatt er synlig etter innsending (scanner/src/login.js). Deretter tømmer den passordfeltet i sidens minne og glemmer påloggingsopplysningene (scanner/src/login.js).
Den leser høyst fem sider på samme domene, angitt av Kunden. Adresser som inneholder ord for utlogging, sletting, fjerning eller avbestilling, sperres (scanner/src/login.js). Ingenting sendes inn bak innloggingen, det tas ingen skjermbilder, og informasjonskapsler og lenker kommer ikke med i resultatet (scanner/src/login.js).
Slettingen er endelig: den krypterte teksten overskrives med tilfeldige data av samme lengde, raden slettes, og ventende jobber tømmes (cfg/login_lib.php). Når domenet slettes, forsvinner raden automatisk via en fremmednøkkel.

6.6 Leveringskontroll

Leveringskontrollen besvarer spørsmålet om en e-post fra kontaktskjemaet faktisk kommer frem, og vurderer dens autentisitetskjennetegn. Den er valgfri, slått av som standard og krever at en kontrollpostkasse er konfigurert (cfg/zustellung_lib.php).

Hvis Kunden slår den på, får domenet en tilfeldig identifikator. Kunden legger inn kontrolladressen med denne identifikatoren som blindkopimottaker i skjemaet sitt.
Fra da av går hver skjema-e-post også til kontrollpostkassen: våre merkede testinnsendinger og alle ekte meldinger fra besøkende. E-postene går direkte til postkassen hos Namecheap, Inc. (Private Email), Phoenix, Arizona, USA – de kommer bare frem hvis MX-oppføringene til domenet vårt peker dit; via videresending, for eksempel hos domeneregistraren Namecheap, Inc., når de ikke postkassen – og blir der til de hentes.
Statusprosessen henter postkassen hvert femte minutt (srv/cron_status.php). For hver e-post leser den hodefeltene og høyst de første 8 KB av teksten, uten å merke dem som lest (cfg/zustellung_lib.php).
Fra hodefeltene fastslår den identifikatoren og dermed domenet, og fra teksten eventuelt identifikatoren til testen vår (cfg/zustellung_lib.php). Tidspunktet, domenet og eventuelt testidentifikatoren lagres (cfg/zustellung_lib.php), i 180 dager (cfg/zustellung_lib.php).
Fra hodefeltene vurderer den SPF, DKIM og DMARC og lagrer resultatet for domenet: kontrollresultatene, domenet i avsenderadressen, domenene i signaturene og adressen til den avsendende e-postserveren (cfg/zustellung_lib.php). Hvis resultatet forverres, sendes et varsel som kan navngi avsenderdomenet, én gang til Kunden (cfg/zustellung_lib.php).
Deretter merker den hver hentede e-post for sletting, også en som ikke kunne tilordnes noe domene, og fjerner den fra postkassen ved slutten av kjøringen (cfg/zustellung_lib.php). Hvis kjøringen avbrytes før dette, blir e-postene liggende til neste vellykkede kjøring.
Bare kopien av akkurat den aktuelle testen regnes som dokumentasjon på levering (cfg/zustellung_lib.php). Hvis den ikke kommer frem innen tre timer (delivery_wait_h), melder tjenesten «Levering mangler».

Teksten i ekte meldinger skrives aldri til databasen, og det gjør heller ikke den besøkendes adresse. Begge leses likevel: hentingen laster de første 8 KB av hver e-post inn i minnet for å søke etter testidentifikatoren.

6.7 Svermbeskyttelse

Beskyttelseslaget i WordPress-programtillegget stopper en melding som søppelpost og teller domenene i lenkene i den. Én gang om dagen rapporterer programtillegget disse domenene med antall treff til oss, høyst 60 per dag; ingen adresser, ingen tekst, ingen IP-adresser (cfg/swarm_lib.php).
Én gang om dagen setter vi sammen listen på dette grunnlaget: et domene tas med hvis det er rapportert innen sju dager fra minst tre forskjellige nettsteder og med minst fem treff (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). Store tjenester fra en fast unntaksliste og våre Kunders domener, i begge tilfeller inkludert underdomener, tas aldri med på listen (cfg/swarm_lib.php).
Listen sendes til alle tilkoblede nettsteder med svaret på den daglige rapporten. Beskyttelseslaget deres legger meldinger med lenker til oppførte domener i karantene, ikke i papirkurven.
Det som ikke lenger står på den nye listen, faller ut; rapporter slettes etter 30 dager (cfg/swarm_lib.php).
IP-nettverk (/24 eller /48) er klargjort, men er slått av til den juridiske gjennomgangen er fullført (cfg/swarm_lib.php).

6.8 Bruk av kunstig intelligens

En språkmodell kjører på vår egen skanneserver, ikke hos en KI-leverandør. Den brukes tre steder: i kontrolltjenesten klassifiserer den skjemaer der reglene ikke gjenkjenner typen; da ser den sidetittelen, sideadressen, etikettene på sendeknappene, felttyper, navn, etiketter og plassholdere samt opptil 400 tegn med skjematekst (scanner/src/classify.js). Den spørres bare hvis reglene gir svaret «unknown»; skjemaer som klassifiseres på denne måten, sendes aldri inn og inngår ikke i poengsummen og konklusjonen. Poengsummen, konklusjonen, forebygging av misbruk, svermbeskyttelsen og søppelpostreglene bygger på faste regler, ikke KI. I «Fix it for me» skriver den om innlimt skjemakode; koden lagres ikke. For kvalifiserte kontroller av domener i betalte kontoer genererer den også en prioritert tiltaksplan ut fra vertsnavnet, samlet resultat og poengsum, CMS, relevant skjematype og sideadresse, eventuelle identifiserte programtillegg og utvalgte funn som viser feil eller er uklare. Forespørselen lagres midlertidig i den interne jobbkøen og slettes etter henting eller planlagt opprydding av oppføringer som er mer enn én time gamle. Den genererte teksten, språket, statusen og tidsstempelet oppbevares sammen med skanneresultatet etter reglene for hvor lenge dette lagres. Rapporten merker planen som et KI-sammendrag og fastslår at de enkelte funnene er avgjørende; planen endrer ikke nettstedet eller skanneresultatet. Modellen treffer ingen avgjørelser om personer. Mer om dette på siden EUs KI-forordning: Slik bruker formexposed KI.

6.9 Rettslige grunnlag

Behandlingsaktivitet	Rettslig grunnlag
P1 Gratis kontroll: kontroll av det forespurte domenet; grenser og forebygging av misbruk	overfor personen som ber om kontrollen, art. 6(1)(b); overfor operatøren og avbildede personer, art. 6(1)(f); forebygging av misbruk, art. 6(1)(f)
P2 Kontroll for en potensiell kunde	Art. 6(1)(f) (byråets og formexposeds berettigede interesse)
P3 Studie	Art. 6(1)(f)
P4 Kontroll av Kundens domener	Art. 6(1)(b) overfor Kunden; for tredjepartsopplysninger på Kundens nettsted, Kundens instrukser etter art. 28
P5 Skanning bak innloggingen	Kundens instrukser etter art. 28; Kundens rettslige grunnlag
P6 Leveringskontroll	Kundens instrukser etter art. 28; Kundens rettslige grunnlag (i vårt tekstforslag til Kunder, art. 6(1)(f))
P7 Svermbeskyttelse	Art. 6(1)(f) (felles forsvar mot søppelpost på tvers av mange nettsteder)

Vår berettigede interesse i P1 til P3 ligger i å vise operatører og deres tjenesteleverandører svakheter i skjemaene før de utnyttes til søppelpost eller misbruk, og i å levere tjenesten. Opplysningene kommer fra offentlig tilgjengelige kilder. Interesseavveiningen er beskrevet i avsnitt 7; om art. 6(1)(f) gir grunnlag for kontroll av tredjeparters nettsteder på forespørsel, er et åpent spørsmål for den juridiske gjennomgangen.

6.10 Mottakere og overføringer til tredjeland

Mottaker	Hva	Behandlingsaktivitet	Status
Ingen utenfor formexposed	Kontrollresultater, skjermbilder, klassifisering utført av språkmodellen	P1–P5	Kontrolltjenesten og språkmodellen kjører på våre egne servere; i søkerobotens kontrollforløp ble det ikke funnet noen anrop til tredjeparter bortsett fra selve nettstedet som kontrolleres, tjenestene nettstedet bygger inn innhold fra (som for enhver besøkende), og RDAP-tjenesten rdap.org for domenets alder (bare domenenavnet); overvåkingskontrollene er oppført i neste rad
Alle som kjenner lenken	Rapport med funn og skjermbilder	P1, P2, P4	tilfeldig lenke med 128 bits (`cfg/check_lib.php`), sider med `noindex` (`www/report.php`)
Tjenester som forespørres av overvåkingen av et Kundedomene	DNS-sperrelister (SpamCop, PSBL, Mailspike, SURBL): domener og IP-adresser til servere, ingen besøksdata; Google Web Risk bare hvis konfigurert: adressen til startsiden; tidsstempelmyndighetene Certum og DigiCert: bare en hashverdi av dokumentasjonsloggen; RDAP via IANA-registeret: bare domenenavnet; leverandørers statussider: ingenting overføres; wpvulnerability.net: identifikatoren til et programtillegg (uten versjon) eller tema og WordPress-versjonen	P4	i bruk; detaljer i Protokoll over behandlingsaktiviteter og på siden Underdatabehandlere
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Kontrollkopier, inkludert ekte meldinger fra besøkende	P6	Avtale ennå ikke inngått; behandlingssted og overføringsmekanisme må fortsatt undersøkes
Namecheap, Inc. (USA)	Registrar og DNS; frem til postkassen er konfigurert, videresending av generelle e-poster til adresser på domenet vårt, men ikke av kontrollkopiene (disse når postkassen bare via MX-oppføringer som peker direkte til den)	– (ingen kontrollkopier)	Overføringsmekanismen må undersøkes
Varslingskanaler valgt av Kunden (e-post, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Hendelse, domene, lenke; ved autentisitetskontrollen avsenderdomenet hvis det ikke tilhører nettstedet	P4, P6	mottakssted valgt av Kunden; delvis utenfor EU. Vi sender Telegram-meldinger via boten vår; overføringsmekanismen for dette er et åpent spørsmål for den juridiske gjennomgangen
Alle tilkoblede nettsteder	Liste over lenkedomener	P7	via svaret til programtillegget
Andre test	Domene, skjemaadresse, selektor, trinn	P4	slått av

6.11 Lagringstid, målt, ikke tilsiktet

Sletting skjer for det meste om natten kl. 03:00 i statusprosessen (srv/cron_status.php, cfg/fristen_lib.php); rapporter om svermbeskyttelse og rader for potensielle kunder slettes daglig fra kl. 04:00, tilordninger fra leveringskontrollen ved hver henting; anonyme rapporter og rapporter for potensielle kunder slettes via utløpsdatoen (cfg/check_lib.php). Skjermbilder slettes fra disken sammen med den tilhørende skanningen (cfg/fristen_lib.php).

Opplysninger	Frist ifølge koden	Kildehenvisning	Funn
Gratis kontroll inkludert bilder	30 dager	`cfg/check_lib.php`	virksom
Kontroll for en potensiell kunde inkludert bilder	90 dager	`cfg/akquise_lib.php`; `srv/cron_status.php` (rader for potensielle kunder)	virksom
Kontroller av et Kundedomene	13 måneder; den siste beholdes så lenge domenet finnes	`cfg/fristen_lib.php`	virksom
Resultater av nettleserforløp inkludert bilder med svarte felt over inndata	13 måneder	`cfg/fristen_lib.php`	virksom
Opplysninger for et slettet domene	umiddelbart; foreldreløse oppføringer om natten	`cfg/fristen_lib.php` (`fe_domain_loeschen()`, `fe_fristen_lauf()`)	virksom, inkludert skriptoversikten og skriptendringene, som ikke har noen egen lagringsfrist utover dette (se Protokoll over behandlingsaktiviteter)
Studie: rådata inkludert bilder	ved publisering	`cfg/studie_lib.php`	uten publisering ingen tidsgrense; listen over kontrollerte verter beholdes uten tidsgrense også etter publisering
Interne kontroller uten domene og uten rapport	ingen	–	ingen sletting; målt: 85 kontroller med 369 bilder siden 22. september 2026 (R4)
Tilordninger fra leveringskontrollen	180 dager	`cfg/zustellung_lib.php`	virksom
Resultatet av autentisitetskontrollen for domenet	til neste resultat eller sletting av domenet	`cfg/zustellung_lib.php`	overskrives, ingen tidsgrense
Kontrollkopier i postkassen	til neste vellykkede henting (intervall på fem minutter)	`cfg/zustellung_lib.php`	kopier og sikkerhetskopier hos postkasseleverandøren er ikke verifisert
Påloggingsopplysninger for skanning bak innloggingen	til Kunden sletter dem eller domenet slettes; i jobben høyst til kjøringen avsluttes, rester etter én time	`cfg/login_lib.php`	virksom; i sikkerhetskopier bare som kryptert tekst i opptil 14 dager
Rapporter i svermbeskyttelsen	30 dager	`cfg/swarm_lib.php`	virksom
Grenser for den gratis kontrollen (IP, land, økthash)	7 dager	`srv/cron_status.php`	virksom
Notater om påfallende atferd med IP-adresse	90 dager etter at saken er løst	`srv/cron_status.php`	uløste notater uten tidsgrense; målt: 3 notater, alle løst
IP-adresse, land, nettleser knyttet til en opt-out	12 måneder; utestengingen beholdes	`cfg/fristen_lib.php`	virksom
Sikkerhetskopier av databasen	14 dager	`cfg/backup_lib.php`	virksom; sikkerhetskopiene lagres for tiden på samme sted som databasen og er ikke kryptert særskilt; en kryptert kopi på et annet sted er planlagt (R13)

7. (b) Vurdering av nødvendighet og forholdsmessighet

Målestokken er de angitte formålene: å vise operatører om skjemaene deres er beskyttet mot søppelpost og misbruk (P1 til P5), å kontrollere om skjema-e-poster kommer frem og fremstår som autentiske (P6), og å forsvare seg i fellesskap mot søppelpost på tvers av mange nettsteder (P7). Disse formålene er legitime. Spørsmålet etter art. 35(7)(b) er snevrere: er denne behandlingen nødvendig i dette omfanget for formålet, og står inngrepet i et rimelig forhold til nytten?

Komponent	Nødvendig for formålet?	Forholdsmessig slik den er bygget?
Henting av noen få offentlige sider, skjemaenes struktur, påviste beskyttelsestiltak	Ja. Uten dette foreligger det ikke noe funn.	Ja. Høyst åtte sider (pluss visningene fra avsnitt 6.1), et forbud mot startsiden i robots.txt respekteres, ingen verdier fra synlige felt, mottakeradresser bare som domene.
Skjermbilde per skjema	Ja, som dokumentasjon i rapporten: operatøren kan se hvilket skjema som menes.	I stor grad. Feltene er tomme fordi søkeroboten ikke skriver inn noe. Bildet viser imidlertid omgivelsene rundt skjemaelementet uten å sladde noe (R3).
Skjermbilde av startsiden	Ikke nødvendig for selve funnet. Det gjør det mulig å gjenkjenne det kontrollerte nettstedet i rapporten.	Bare i begrenset grad; ytterligere minimering er planlagt. Startsider viser ofte personer: teambilder, kontaktpersoner, kundeuttalelser med navn. Se R3 og avsnitt 9.3.
Lesing av verdiene i skjulte felt (de første 24 tegnene, bare under kontrollen)	Ja: tokener og tidsstempler oppdages ut fra disse.	Ja. Bare påvisningsresultatet lagres, ikke verdien, også bak innloggingen (R8).
Svarsiden etter testinnsendingen (bilde og 300 tegn med tekst)	Ja, som dokumentasjon på hvordan skjemaet svarte.	Ja. Svaret gjelder vår merkede testmelding uten personopplysninger.
Klassifisering utført av språkmodellen	Nyttig, ikke nødvendig: uten den forblir flere skjemaer «unknown».	Ja. Lokalt, uten utlevering, uten rett til å sende inn.
Lokal tiltaksplan fra utvalgte funn og skannemetadata	Nyttig for å prioritere utbedringer, ikke nødvendig for å frembringe de enkelte funnene.	Begrenset til eksisterende skannemetadata og høyst 18 forskjellige funn som viser feil eller er uklare, uten skjermbilder eller innskrevne feltverdier i instruksen. Planen er veiledende og merket som KI-generert; de enkelte funnene forblir avgjørende. Nettadresser og notater kan fortsatt inneholde personopplysninger, og den genererte teksten følger skanningens lagringstid og tilgang for den som har lenken. Disse grensene reduserer eksponeringen, men beviser ikke faktisk riktighet (R10).
Aktive testinnsendinger	Ja. Om en beskyttelse virker, viser seg først når den testes.	Ja, med en øvre grense og merking. Forutsetningen – dokumentasjon på råderett – fornyes imidlertid aldri (R7).
Søk etter eksponerte filer	Ja for Kunden, hvis skjemadata kan være eksponert der.	Ja. Bare bekreftede domener, høyst 8 KB, innhold lagres aldri.
Skanning bak innloggingen	Ja for skjemaer i medlemsområdet som ellers ville forbli ukontrollert.	I stor grad. Kryptering og sletting er omhyggelig utformet; innloggingen godtar imidlertid ukrypterte forbindelser og feilaktige sertifikater (R8).
Kontrollkopi av ekte meldinger fra besøkende	Ikke for dokumentasjon på levering. Den bygger bare på kopien av testen vår (`cfg/zustellung_lib.php`). Ekte meldinger følger med fordi en blindkopi i skjemaet ikke skiller mellom en test og en ekte melding. De er nyttige for autentisitetskontrollen (SPF, DKIM, DMARC) fordi de viser den faktiske avsendingsveien.	Delvis. Innhold lagres ikke, men leses, og det blir liggende hos postkasseleverandøren, hvis avtale fortsatt er uavklart, frem til henting (R1, R2). En mindre inngripende utforming er teknisk mulig: med vårt programtillegg kunne blindkopien begrenses til merkede testmeldinger (avsnitt 9.3).
Lagring av avsenderdomenet til ekte meldinger	Delvis: det viser om skjemaet sender med den besøkendes adresse som avsender (en vanlig årsak til klassifisering som søppelpost).	På vilkår. For en enkeltperson med eget domene er domenet en personopplysning, og det tas med i varselet til Kunden og Kundens kanaler (R1).
Felles liste over lenkedomener	Ja. En søppelpostlenke som opptrer på mange nettsteder samtidig, er et sterkt signal som et enkelt nettsted ikke har.	Ja, med minsteantall, unntak og karantene i stedet for sletting. IP-nettverk ville ikke være forholdsmessige uten en ny vurdering.
Rådata fra studien	Frem til evalueringen, ja.	Uten en lengste frist, nei (R4).
Rapport under en tilfeldig lenke	Ja. Å dele rapporten videre – for eksempel med tjenesteleverandøren som tar hånd om nettstedet – er formålet med den gratis kontrollen.	Ja. Tilfeldig lenke med 128 bits, `noindex`, gratis rapport bare som utdrag (`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`), sletting etter 30 dager.

Lovlighet. For P1 til P3 og P7 støtter vi oss på art. 6(1)(f). Momenter som taler for i avveiningen: opplysningene er offentlige og hentes på samme måte som enhver besøkende gjør; ingenting sendes inn; personopplysninger forekommer tilfeldig og i lite omfang; fristene er korte; operatøren kan utelukke videre kontroller utført av søkeroboten gjennom et forbud mot startsiden i robots.txt og enhver videre kontroll gjennom vår opt-out-side, umiddelbart og uten dokumentasjon; nytten – et beskyttet skjema – tilfaller også operatøren og de besøkende. Momenter som taler imot: operatøren får ikke vite om kontrollen, rapporten er beregnet på tredjeparter, og for enkeltpersonforetak vurderer den en person. Vi anser avveiningen som forsvarlig så lenge tiltakene fra avsnitt 9.1 opprettholdes; juridisk bekreftelse avventes.

Informasjon til de registrerte (art. 13 og 14). Vi informerer operatører og personer på kontrollerte sider gjennom søkerobotsiden, som er nevnt i identifikatoren ved hver henting, gjennom Personvernerklæring og gjennom opt-out-siden. Å informere hver enkelt person som tilfeldigvis vises i et skjermbilde, ville bare være mulig hvis vi identifiserte vedkommende – noe som ville innebære et ytterligere og mer alvorlig inngrep. I den utstrekning støtter vi oss på art. 14(5)(b). Besøkende hvis meldinger går gjennom kontrollkopien, informeres av Kunden; Databehandleravtale krever dette, og vi stiller en tekstblokk til rådighet for formålet.

Dataminimering (art. 5(1)(c)). Den er synlig mange steder og forankret i koden: ingen feltverdier, mottakeradresser bare som domene, kontoidentifikatorer i skriptadresser skjult, intet innhold fra kontrollkopien i databasen, ingen skjermbilder bak innloggingen, bare domener i svermbeskyttelsen. To steder er ytterligere minimering mulig og planlagt (avsnitt 9.3): for skjermbildet av startsiden uten sladding og for avsenderdomenet til ekte meldinger.

Lagringsbegrensning (art. 5(1)(e)). Siden 27. september 2026 har den nattlige kjøringen overholdt fristene i Personvernerklæringen for Kundeopplysninger og fjernet gjenværende opplysninger uten tilknyttet domene fra tiden før dette (cfg/fristen_lib.php). To behandlingsforløp uten tidsgrense er fortsatt åpne: interne kontroller og upubliserte studier (R4).

Riktighet (art. 5(1)(d)). Et funn kan være feil: et skjema fremstår som ubeskyttet fordi beskyttelsen først lastes etter en interaksjon, eller søkeroboten ble behandlet annerledes av en brannmur enn en besøkende. For en operatør hvis nettsted deles offentlig som «Eksponert», handler dette om omdømme. Rapporten oppgir derfor metoden, viser dokumentasjon og påpeker begrensningene ved en kontroll utenfra.

Resultat om forholdsmessighet: Kontroll av tredjeparters og egne nettsteder er i sin nåværende utforming i hovedsak forholdsmessig. Tre steder finnes det forbedringsbehov som kan avhjelpes med vanlige midler, og der tiltak er planlagt (avsnitt 9.3): skjermbildene av startsiden, de interne kontrollene uten tidsgrense og den ukrypterte innloggingen ved skanning bak innloggingen. Leveringskontrollen er forholdsmessig for testkopien og for autentisitetskontrollen; for ekte meldinger fra besøkende gjelder dette bare så lenge innholdet ikke lagres, forløpet via postkasseleverandøren er sikret gjennom avtale, og Kunden informerer de besøkende. I dag mangler det andre av disse tre punktene.

8. (c) Vurdering av risikoene for de registrertes rettigheter og friheter

Det som vurderes, er risikoen for de registrerte, ikke for formexposed. Sannsynligheten vurderes som liten, mulig, sannsynlig eller inntruffet; «inntruffet» betyr at hendelsen ikke er en prognose, men en målt tilstand. Alvorlighetsgraden vurderes som begrenset, betydelig, alvorlig eller svært alvorlig, avhengig av hva personen kan miste: meldingens fortrolighet, kontrollen over en konto, sitt forretningsmessige omdømme, muligheten til å utøve en rettighet. Nivået følger av begge og beskriver den nåværende tilstanden med tiltakene fra avsnitt 9.1.

Nr.	Risiko	Behandlingsaktivitet	Sannsynlighet	Alvorlighetsgrad	Nivå
R1	Ekte meldinger fra besøkende i kontrollkopien, inkludert mulige særlige kategorier	P6	Inntruffet så snart funksjonen slås på	Alvorlig	Høy
R2	Kontrollkopiens forløp via postkasseleverandøren uten inngått avtale og med mulig tredjelandstilknytning	P6	Sannsynlig så lenge avtalen mangler	Alvorlig	Høy
R3	Skjermbilder av tredjeparters nettsteder uten sladding	P1–P4	Sannsynlig	Begrenset	Middels
R4	Kontrolldata og skjermbilder uten slettingsforløp	P3, interne kontroller	Inntruffet	Betydelig	Høy
R5	Kontroll og offentlig vurdering av tredjeparters nettsteder uten operatørens kjennskap; misbruk som rekognoseringsverktøy	P1	Mulig	Betydelig	Middels
R6	Kontroll for en potensiell kunde som grunnlag for uanmodede henvendelser	P2	Sannsynlig	Begrenset	Middels
R7	Dokumentasjon på råderett fornyes aldri	P4, P5	Mulig	Betydelig	Middels
R8	Påloggingsopplysninger og innhold ved skanning bak innloggingen	P5	Mulig	Alvorlig	Middels; høy for reelle kontoer
R9	Aktive testinnsendinger og filkontroll på Kundens nettsted	P4	Liten	Betydelig	Lav
R10	Klassifisering utført av en språkmodell	P1–P4	Liten	Begrenset	Lav
R11	Felles sperreliste basert på rapporter fra mange nettsteder	P7	Mulig	Begrenset	Lav til middels; høy med IP-nettverk
R12	Rapporter og skjermbilder under en offentlig lenke	P1, P2, P4	Mulig	Begrenset	Lav
R13	Svakheter i infrastrukturen: sikkerhetskopier, servertilgang, skanneserver	alle	Mulig	Alvorlig	Høy
R14	Registrertes rettigheter for personer som ikke kjenner oss	P1–P6	Sannsynlig	Begrenset	Lav

R1 – Ekte meldinger fra besøkende i kontrollkopien

Dette er tjenestens mest alvorlige risiko, og den skyldes ikke en feil, men utformingen. En blindkopi i skjemaet skiller ikke mellom testmeldingen vår og en besøkendes melding. Hvis en Kunde slår på leveringskontrollen, når hver melding som sendes via det skjemaet, kontrollpostkassen vår (cfg/zustellung_lib.php). Hentingen leser hodefeltene og de første 8 KB av teksten inn i minnet for å søke etter testidentifikatoren vår (cfg/zustellung_lib.php). For et vanlig kontaktskjema betyr det navn, e-postadresse, telefonnummer og hele meldingen.

Hva den besøkende skriver, bestemmer vedkommende selv, og feltet innbyr til personlig innhold: en timebestilling med beskrivelse av symptomer til en legepraksis, en redegjørelse for en rettstvist til et advokatfirma, en jobbsøknad, en forespørsel om et barn til en skole. Våre juridiske dokumenter sier at kopier «ikke bør inneholde særlige kategorier av personopplysninger». Det er en oppfordring til Kunden, ikke et beskyttelsestiltak: verken Kunden eller vi vet på forhånd hva en besøkende vil skrive.

To sideforløp hører med til dette. For det første lagrer autentisitetskontrollen domenet i avsenderadressen for domenet (cfg/zustellung_lib.php). Hvis skjemaet sender med den besøkendes adresse som avsender, er dette den besøkendes domene – uten betydning for en stor e-postleverandør, men en personopplysning for en enkeltperson med eget domene. Dette domenet vises også i varselet som sendes til Kunden og kanalene Kunden har valgt (cfg/zustellung_lib.php). For det andre lagres adressen til den avsendende e-postserveren (cfg/zustellung_lib.php); som regel er dette nettstedets server, ikke den besøkendes.

Sannsynlighet – inntruffet så snart funksjonen slås på. Spørsmålet er ikke om ekte meldinger kommer frem, men hvor mange. Målt på utviklingssystemet er funksjonen ikke slått på for noe domene. Alvorlighetsgrad – alvorlig. Fortroligheten til en melding til en virksomhet er viktig for mange mennesker, og opplysninger etter art. 9 må forventes hos enkelte typiske Kunder. Alvorlighetsgraden dempes av at innholdet ikke kommer inn i databasen, bare blir liggende kort i postkassen og ikke leses av noen person hos formexposed. Nivå – høyt.

R2 – Kontrollkopiens forløp via postkasseleverandøren uten inngått avtale

Før hentingen vår ser en kontrollkopi, ligger den i postkassen hos Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Den kommer bare dit hvis MX-oppføringene til domenet vårt peker direkte til denne postkassen; videresending hos domeneregistraren Namecheap, Inc. er ikke et mellomledd for kontrollkopiene (via videresending når de ikke postkassen). For det gjenværende mellomleddet er avtaleforholdene fortsatt uavklart: avtalen med postkasseleverandøren er ikke inngått, lagringsstedene, underdatabehandlerne og sikkerhetskopifristene er ikke fastslått, og det er uavklart om en beslutning om tilstrekkelig beskyttelsesnivå eller standard personvernbestemmelser kreves og får anvendelse for behandlingsstedet. For våre egne transaksjonsrelaterte e-poster er dette et spørsmål om avtaleutforming. For kontrollkopiene er det mer alvorlig: der gjelder det opplysninger vi mottar som databehandler, og hver tjenesteleverandør underveis er en underdatabehandler som vi er ansvarlige for etter art. 28(4).

I tillegg gjelder «slettet etter henting» bare vårt innsyn i postkassen. Om leverandøren oppbevarer slettede e-poster i egne sikkerhetskopier eller i en papirkurv, og hvor lenge, er ikke verifisert. Hvis en henting avbrytes, blir e-postene liggende til neste vellykkede kjøring (cfg/zustellung_lib.php); hvis statusprosessen svikter, blir de liggende på ubestemt tid. Til slutt er sikring av selve hentingen et av punktene som må kontrolleres på produksjonssystemet før lansering (avsnitt 9.3).

Sannsynlighet – sannsynlig så lenge avtalen mangler: hver kontrollkopi følger dette forløpet. Alvorlighetsgrad – alvorlig, av samme grunner som R1. Nivå – høyt. Applikasjonens sjekkliste for oppsett rapporterer den manglende postkassen som et varsel; det finnes ingen sperre som blokkerer leveringskontrollen uten en dokumentert avtale.

R3 – Skjermbilder av tredjeparters nettsteder uten sladding

Søkeroboten tar et skjermbilde av det synlige området på den første siden og et bilde av skjemaelementet for hvert synlige skjema (scanner/src/crawl.js). Ingenting sladdes i denne prosessen. Dette er annerledes for nettleserforløp: der maskeres inndatafeltene før skjermbildet tas (scanner/src/browser.js). Dermed er bare bildene fra nettleserforløp «renset», ikke bildene fra søkeroboten og ikke bildet av svarsiden fra en aktiv kontroll.

Fordi søkeroboten ikke skriver inn noe, er skjemafeltene tomme. Startsiden til en liten virksomhet viser imidlertid ofte eieren, teamet, kundeuttalelser med navn og bilder eller et chattevindu med bildet av en ansatt. Alt dette er offentlig; skjermbildet gjør det til en kopi som lagres hos oss, vises i rapporten og kan deles videre med lenken.

Sannsynlighet – sannsynlig. Det ble målt 432 skjermbilder i datasettet til utviklingssystemet. Alvorlighetsgrad – begrenset: innholdet er allerede offentlig, og fristene for kontroller uten konto er korte. Nivå – middels, fordi de avbildede personene ikke kjenner til dette, og bildet av startsiden ikke er nødvendig for funnet.

R4 – Kontrolldata og skjermbilder uten slettingsforløp

Den nattlige kjøringen sletter kontroller via to forløp: via utløpsdatoen til en rapport (cfg/check_lib.php) og via fristen for kontroller av et Kundedomene (cfg/fristen_lib.php, bare for kontroller med et domene). En kontroll som verken har rapport eller domene, faller utenfor begge. Dette er kontrollene med tillitsnivået «internal»: studier og kontroller leverandøren oppretter fra kommandolinjen.

Studier sletter rådataene ved publisering (cfg/studie_lib.php). Hvis en studie aldri publiseres – fordi den har for få nettsteder med et skjema (cfg/studie_lib.php nekter da publisering), eller fordi den blir liggende – beholdes kontroller, skjemaer, funn og skjermbilder uten tidsgrense.
Interne kontroller fra kommandolinjen har ikke noe slettingsforløp overhodet. Målt 11. oktober 2026: 85 slike kontroller av tredjeparters nettsteder med 978 skjemaer og 369 skjermbilder, den eldste fra 22. september 2026, ingen med rapport eller domene.
Notater om påfallende atferd i den gratis kontrollen inneholder IP-adressen og slettes 90 dager etter at saken er løst (srv/cron_status.php). Et notat der saken aldri løses, beholdes. Målt: tre notater, alle løst.

Sannsynlighet – inntruffet. De 85 kontrollene er ikke et scenario, men eksisterende data. På utviklingssystemet er dette kontroller fra en felttest; samme kode gjelder på produksjonssystemet. Alvorlighetsgrad – betydelig: det finnes ingen lagringsfrist for disse opplysningene. Med hensyn til prinsippet om lagringsbegrensning (art. 5(1)(e)) er dette et åpent punkt med et planlagt tiltak (avsnitt 9.3, prioritet «først»), og det berører nettopp personer som ikke vet noe om kontrollen. Interne kontroller er beskrevet i Protokoll over behandlingsaktiviteter; Personvernerklæringen nevner dem ennå ikke særskilt (avsnitt 9.4). Nivå – høyt.

R5 – Kontroll og offentlig vurdering av tredjeparters nettsteder uten operatørens kjennskap

Hvem som helst kan få et hvilket som helst offentlig tilgjengelig nettsted kontrollert, uten konto og uten noen tilknytning til det. Operatøren varsles ikke. Resultatet er en rapport som vurderer nettstedet som «Ubeskyttet», «Delvis beskyttet» eller «Beskyttet», og som alle med lenken kan se. To konsekvenser er tenkelige for de registrerte. Et enkeltpersonforetak gis en vurdering offentlig – selv om det bare er for mottakerne av lenken – som kan være et feilaktig funn. Og rapporten viser en søppelpostavsender hvilket skjema som kan fylles ut uten hindring.

En rekke sperrer står imot dette (cfg/check_lib.php): høyst én kontroll per domene i løpet av sju dager, deretter samme rapport; grenser per IP-adresse og økt; en daglig øvre grense for hele tjenesten; ingen kontroller av svært nye domener, som er typiske ved misbruk; et notat og et signal ved påfallende atferd; robots.txt og opt-out, kontrollert to ganger (cfg/check_lib.php og i kontrolltjenesten). Den gratis rapporten er et utdrag: den viser bare de grunnleggende funnene, ikke dokumentasjonen fra alle detektorer. Og den sier ingenting som en bot ikke selv kunne finne ut på sekunder – et ubeskyttet skjema er synlig utenfra.

Sannsynlighet – mulig. Alvorlighetsgrad – betydelig for et enkeltpersonforetak hvis skjema blir mål for angrep etter en rapport, eller hvis vurdering er feil. Nivå – middels.

R6 – Kontroll for en potensiell kunde som grunnlag for uanmodede henvendelser

I grensesnittet beskrives kontrollen for potensielle kunder som en «døråpner for den første samtalen». Hvordan byrået bruker det korte funnet, avgjør byrået selv; teknisk sett kan det også sende det til en operatør som ikke har bedt om det. Vi kontakter ingen (cfg/akquise_lib.php), og Bruksvilkår pålegger byrået å overholde reglene om reklame og kundehenvendelser. En uanmodet e-post med funnet er imidlertid direkte markedsføring også mellom virksomheter, noe som i Polen (art. 398 i loven om elektronisk kommunikasjon (Prawo komunikacji elektronicznej, PKE)) og i Tyskland (§ 7(2) i den tyske loven mot illojal konkurranse (Gesetz gegen den unlauteren Wettbewerb, UWG)) krever forhåndssamtykke. Grensesnittet påpeker ikke dette; tekstene i kontrollen for potensielle kunder omtaler bare «passiv» og «opt-out-liste».

Sannsynlighet – sannsynlig, fordi funksjonen brukes til kundeanskaffelse og vi ikke kan verifisere om mottakeren har samtykket. Alvorlighetsgrad – begrenset: for operatøren er det en irriterende markedsførings-e-post med en vurdering av nettstedet. Nivå – middels. Risikoen ligger i byråets atferd; fordi funksjonen kommer fra oss, er en merknad i grensesnittet planlagt (avsnitt 9.3).

R7 – Dokumentasjon på råderett fornyes aldri

Aktive testinnsendinger, søket etter eksponerte filer og skanningen bak innloggingen krever at Kunden har dokumentert rett til å råde over domenet. Denne dokumentasjonen kontrolleres én gang (cfg/verify_lib.php) og aldri igjen. Det finnes ikke noe forløp i koden som gjør at et domene mister dokumentasjonen sin. Hvis domenet skifter eier, et byrå avslutter oppdraget sitt, eller operatøren fjerner DNS-oppføringen, fortsetter kontrollene – opptil daglig, med opptil fem testinnsendinger og, der den er lagret, med innloggingen til en testkonto som den nye operatøren kanskje ikke kjenner til. Det som derimot ikke er mulig, er å overføre dokumentasjonen til en annen vert ved navneendring: vertsnavnet til et domene med dokumentert råderett kan ikke endres.

Sannsynlighet – mulig: bytte av domene og oppdrag forekommer daglig hos byråer. Alvorlighetsgrad – betydelig for den nye operatøren og de ansatte, som mottar merkede testmeldinger, og hvis nettsted gjennomsøkes etter eksponerte filer uten deres samtykke. Nivå – middels. Testmeldingene forklarer seg selv og viser til søkerobotsiden og opt-out; opt-out virker også mot kontroller utført av Kunder.

R8 – Påloggingsopplysninger og innhold ved skanning bak innloggingen

Krypteringen av påloggingsopplysningene er omhyggelig utformet: webserveren kan ikke lenger lese dem etter lagring, databasen og sikkerhetskopien inneholder bare kryptert tekst, posten er bundet til domenet sitt, opplysningene kommer inn i containeren bare via standard inndata og fjernes deretter fra minnet (avsnitt 6.5). To mangler gjenstår; et tredje punkt gjelder bare lesing, ikke lagring.

Ukryptert innlogging er tillatt. Adressekontrollen tillater http i tillegg til https (cfg/login_lib.php, scanner/src/login.js). Hvis Kunden angir en innloggingsside med http, sendes brukernavnet og passordet over internett i klartekst ved hver kontroll.
Sertifikatfeil stopper ikke innloggingen. Innloggingen avbrytes for tiden ikke når sertifikatet til Kundens nettsted er ugyldig (scanner/src/login.js). Sertifikatet beskytter derfor ikke påloggingsopplysningene fullt ut på vei til Kundens nettsted. Avbrudd ved sertifikatfeil er planlagt (avsnitt 9.3, prioritet «først»).
Verdier i skjulte felt bak innloggingen leses, men lagres ikke. Søkeroboten leser de første 24 tegnene i verdien til skjulte felt (scanner/src/crawl.js), og samme uttrekksfunksjon kjører bak innloggingen (scanner/src/login.js). Der inneholder skjulte felt ofte et kontonummer, en brukeridentifikator eller e-postadressen til den innloggede kontoen; bare feltnavnet, typen, etiketten og påvisningsresultatet kommer imidlertid med i feltoversikten og funnene.

I tillegg kommer det koden ikke kan forhindre: Kunden bekrefter at den bruker en testkonto med færrest mulig rettigheter (cfg/login_lib.php), men kan legge inn en reell administratorkonto. Kunden bestemmer hvilke sider skanneren deretter leser; adresser som inneholder ord for utlogging og sletting, sperres, men andre handlinger som et nettsted utløser via en enkel forespørsel, sperres ikke.

Sannsynlighet – mulig. Alvorlighetsgrad – alvorlig hvis en konto med omfattende rettigheter berøres; medlemsområdet med alle brukernes opplysninger er da åpent. Nivå – middels for en testkonto med få rettigheter, høyt for en reell konto. Målt på utviklingssystemet er ingen testkonto lagret.

R9 – Aktive testinnsendinger og filkontroll på Kundens nettsted

En testinnsending går til personene som leser Kundens skjema-e-poster – Kundens ansatte eller en tjenesteleverandør. Den inneholder ingen personopplysninger: avsenderen er dummy@formexposed.com, teksten og emnet er merket og oppgir kontrollidentifikatoren (scanner/src/active.js). Risikoen ligger i feilklassifisering: hvis skanneren oppfattet et søknads-, bestillings- eller rådgivningsskjema som et kontaktskjema, ville testmeldingen havne i en prosess som får konsekvenser. Mot dette står de strenge reglene for «submittable» (scanner/src/classify.js), sperren for domener til offentlige myndigheter, utdanningsinstitusjoner, klinikker, legepraksiser, politi og domstoler (scanner/src/classify.js) og at språkmodellen er utelukket fra denne avgjørelsen (scanner/src/classify.js). Fra svaret lagres statusen, måladressen, tittelen, 300 tegn med tekst og et bilde; de gjelder testmeldingen vår.

Filkontrollen leser høyst 8 KB fra typiske stier. Hvis en databaseeksport faktisk er eksponert der, kan disse 8 KB inneholde skjemaoppføringer fra besøkende. De kontrolleres bare for en signatur og forkastes (cfg/dateien_lib.php); det som lagres, er stien, typen og alvorlighetsgraden.

Sannsynlighet – liten. Alvorlighetsgrad – betydelig. Nivå – lavt. Målt på utviklingssystemet finnes det én aktiv kontroll i datasettet, uten noen godtatt innsending.

R10 – Klassifisering utført av en språkmodell

For skjemaer reglene ikke gjenkjenner, mottar språkmodellen sidetittelen, adressen, knappetekstene, feltbeskrivelsene og opptil 400 tegn med skjematekst (scanner/src/classify.js). Dette kan omfatte et navn, for eksempel «Din kontaktperson: …». Den kjører på vår egen server; i koden sendes ingenting til en tredjepart. Om modellprogramvaren loggfører forespørsler, er ikke verifisert. Resultatet bestemmer bare skjematypen som vises, og kan ikke gjøre et skjema mulig å sende inn; en feilklassifisering fører til et dårligere funn, ikke til en handling.

Sannsynlighet – liten. Alvorlighetsgrad – begrenset. Nivå – lavt.

R10 – Ekstra trinn for tiltaksplan

For kvalifiserte betalte rapporter genererer den samme lokale modellen også veiledende trinn fra utvalgte funn og skannemetadata. I motsetning til klassifisering er resultatet et sammendrag på naturlig språk som lagres sammen med skanningen. Vertsnavn, sideadresser og notater kan inneholde personopplysninger som modellen kan gjenta. En feilaktig anbefaling kan få en leser til å svekke beskyttelsen eller gjøre en unødvendig endring; videreformidling av en rapportlenke kan utlevere gjentatte personopplysninger til en annen mottaker. Koden utfører ikke anbefalingen automatisk, endrer ikke poengsummen eller konklusjonen og kontrollerer ikke om teksten er faktisk riktig. Den begrenser lengden på inndata og utdata, merker sammendraget som KI-generert og oppgir at de enkelte funnene er avgjørende. Dette er kontrolltiltak, ikke bevis på at anbefalingene er riktige eller at rapporten er anonym. Den tidligere vurderingen av sannsynlighet og alvorlighetsgrad for klassifisering vurderer ikke i seg selv dette ekstra genereringstrinnet; den gjenværende risikoen må vurderes ut fra de faktiske opplysningene og bruken av den underliggende kontrollen.

R11 – Felles sperreliste basert på rapporter fra mange nettsteder

Et domene på listen fører til at meldinger med lenker til det havner i karantene på alle tilkoblede nettsteder. Hvis domenet tilhører en enkeltperson – en håndverker, en fotograf, en blogg – når meldingene med lenke til personens eget nettsted mottakerne sent. Et slikt domene kan havne på listen fordi søppelpostavsendere misbruker det, eller fordi noen bevisst sender meldinger som blir stoppet, med domenet i til flere nettsteder.

Mot dette står (cfg/swarm_lib.php): minst tre forskjellige nettsteder og fem treff innen sju dager; faste unntak for store tjenester; aldri våre Kunders domener; manuell fjerning via et verktøy på serveren; karantene i stedet for sletting; listen bygges opp på nytt daglig, og det som ikke lenger rapporteres, faller ut. De berørte kan ikke se listen og har ingen egen fremgangsmåte for å kreve fjerning, annet enn gjennom oss.

Sannsynlighet – mulig. Alvorlighetsgrad – begrenset, fordi ingenting går tapt og mottakeren kan frigi meldingen. Nivå – lavt til middels. Med IP-nettverk slått på ville nettverkene til hele leverandører bli berørt, IP-adresser er personopplysninger, og alvorlighetsgraden ville stige til betydelig: høyt.

R12 – Rapporter og skjermbilder under en offentlig lenke

Rapporter fra den gratis kontrollen, kontrollen for potensielle kunder og kontrollene av Kundedomener er tilgjengelige uten innlogging under en tilfeldig lenke. Lenken inneholder 128 bits tilfeldighet og kan ikke gjettes (cfg/check_lib.php). Sidene har noindex, applikasjonen sender en referrer-policy som bare videreformidler opprinnelsen (www/.htaccess), og skjermbilder leveres bare sammen med rapporten de tilhører; et annet bildenummer gir «ikke funnet» (www/shot.php). Risikoen er ikke kryptografisk, men menneskelig: en lenke deles videre, kopieres inn i en sak, deles i en chat. Den som åpner den, registreres bare i sidetilgangsloggen som ved enhver sidevisning (60 dager), der selve lenken bare vises i maskert form; det finnes ingen leserliste per rapport.

Sannsynlighet – mulig. Alvorlighetsgrad – begrenset, fordi rapporten bare viser offentlig informasjon og utløper etter henholdsvis 30 eller 90 dager; rapporter om Kundedomener forblir tilgjengelige så lenge kontrollen finnes (13 måneder, den siste lenger). Nivå – lavt.

R13 – Svakheter i infrastrukturen

Følgende punkter er oppført som åpne i vår interne gjennomgangspakke og glattes ikke over her. Vi beskriver dem så presist som Kundene trenger for sin egen vurdering, men ikke så presist at beskrivelsen viser en angriper veien; vi gir detaljene til en tilsynsmyndighet på forespørsel.

Sikkerhetskopier av databasen lagres for tiden på samme sted som databasen og er ikke kryptert særskilt; en kryptert kopi på et annet sted er planlagt (cfg/backup_lib.php). Frem til da beskytter de ikke mot tap av stedet, og den som får tak i databasen, får også tak i sikkerhetskopiene. Påloggingsopplysningene for skanning bak innloggingen finnes bare som kryptert tekst i dem.
Ingen kryptering av databasen i hvile. Unntakene er feltene som krypteres enkeltvis (påloggingsopplysninger til testkontoene, tofaktorhemmelighet).
Forbindelser i vårt interne nettverk er ikke gjennomgående kryptert.
Serveradministrasjon. Sikkerheten ved administrativ tilgang til serverne våre oppfyller ennå ikke standarden vi tar sikte på for drift; herdingen av serveradministrasjonen fortsetter.
Kontrollmiljø. Skanneserveren åpner tredjeparters nettsteder i en nettleser. Kontrollcontainerne er isolert – eget nettverk, ingen særlige rettigheter, skrivebeskyttet, begrenset (scanner/src/worker.js). Skillet mellom kontrollmiljøet og de andre delene av tjenesten styrkes ytterligere (avsnitt 9.3).

Sannsynlighet – mulig. Alvorlighetsgrad – alvorlig, fordi alt ville bli berørt samtidig i en nødssituasjon. Nivå – høyt. De enkelte punktene kan avhjelpes med vanlige midler (avsnitt 9.3).

R14 – Registrertes rettigheter for personer som ikke kjenner oss

Den som tilfeldigvis vises i et skjermbilde, eller hvis melding har gått gjennom en kontrollkopi, vet vanligvis ikke at vi finnes. Selv om vedkommende vet det, har personen ingen nøkkel til «sine» opplysninger: vi lagrer dem ikke etter person, men etter domene og kontroll. Vi kan bare besvare en innsynsbegjæring etter art. 15 hvis personen oppgir domenet; da kan vi gå gjennom de eksisterende kontrollene og bildene. For ekte meldinger fra besøkende finnes det ingenting å utlevere, fordi vi ikke lagrer dem – bortsett fra avsenderdomenet fra R1. Opt-out virker bare for operatører av et domene, ikke for avbildede personer; for dem gjenstår henvendelse via contact@lukaswojcik.com.

Sannsynlighet – sannsynlig som en strukturell situasjon. Alvorlighetsgrad – begrenset, fordi opplysningene er kortlivede og ikke organisert etter person. Nivå – lavt.

9. (d) Tiltak for å håndtere risikoene

Hvert tiltak har en status, og statusene er ikke pynt. Gjennomført i dag – verifisert betyr: lest i koden til utviklingssystemet og, der det er mulig, målt mot databasen. Delvis betyr: mekanismen finnes, men oppfyller ennå ikke formålet fullt ut. Planlagt betyr: foreslått i denne vurderingen og ikke bygget; eieren avgjør om og når. Må fortsatt fastsettes gjelder prosedyrer og beslutninger som ingen kode erstatter. En vurdering av personvernkonsekvenser som fremstiller planlagte tiltak som gjennomført, mister verdien sin nettopp i situasjonen der den trengs.

9.1 Gjennomført i dag – verifisert

Tiltak	Håndterer	Kildehenvisning
robots.txt leses av søkeroboten før hver kontroll; en utestenging som omfatter startsiden, en utilgjengelig robots.txt eller en serverfeil avslutter kontrollen (understier overholdes ikke enkeltvis; puls, henting av dokumentasjon, verktøyet for HTTP-hoder og filsøk leser den ikke)	R5, lovlighet	`scanner/src/net.js`
Opt-out uten dokumentasjon, med umiddelbar virkning, for domenet og www-varianten, for anonyme kontroller, potensielle kunder, studier og Kundekontroller (pågående overvåking avsluttes ved neste planlagte kontroll); kontrollert to ganger (applikasjon og kontrolltjeneste); oppheves bare av oss på forespørsel med dokumentasjon	R5, R7, art. 21	`cfg/check_lib.php`; `cfg/akquise_lib.php`; `cfg/studie_lib.php`; `scanner/src/worker.js`
Gratis kontroll: nødstopp, reCAPTCHA, én kontroll per domene og uke, grenser per IP-adresse og økt, daglig øvre grense, ingen nye domener, bare offentlige adresser, notat og signal uten innhold ved avvik	R5	`cfg/check_lib.php`
For grenser lagres økten bare som en hashverdi, aldri øktidentifikatoren	Minimering	`cfg/check_lib.php`
Ingen feltverdier (begynnelsen av skjulte felt og dataattributter leses bare under kontrollen, avsnitt 6.2); mottakeradresser bare som domene; kontoidentifikatorer i skriptadresser skjult	Minimering	`scanner/src/crawl.js`
Den gratis rapporten er et utdrag: bare grunnleggende funn, ingen dokumentasjon fra alle detektorer	R5	`cfg/check_lib.php`, `FE_FREE_DETEKTOREN`
Rapporter under en tilfeldig lenke med 128 bits, `noindex`, bilder bare for egen rapport, utenfor den offentlige webmappen; lenken vises bare i maskert form i sidetilgangsloggen	R12	`cfg/check_lib.php`; `www/report.php`; `www/shot.php`
Sletting: anonyme rapporter etter 30 dager, potensielle kunder etter 90 dager, Kundekontroller etter 13 måneder (den siste per domene beholdes så lenge domenet finnes), opplysningene for et slettet domene umiddelbart (unntak i avsnitt 6.11), bilder i hvert tilfelle sammen med disse	Lagringsbegrensning	`cfg/check_lib.php`; `cfg/fristen_lib.php`
Studie: publisering bare som samlede tall, segmenter bare fra 20 nettsteder med et skjema, rådata slettet ved publisering	R4 delvis, P3	`cfg/studie_lib.php`
Kontrollcontainere: eget isolert nettverk, ingen særlige rettigheter, skrivebeskyttet, minne- og prosessgrenser, tidsgrense; filter mot private mål for hver forespørsel, service workers blokkert og WebSocket-forbindelser lukket slik at ingenting omgår filteret; forespørsler fra webserveren bare på webporter og bare til nøyaktig den offentlige adressen som er kontrollert på forhånd	R13	`scanner/src/worker.js`; `scanner/src/net.js`
Aktiv kontroll for Kunder bare for et bekreftet domene (internt også for våre egne test- og demodomener) og med nødstoppen slått på, kontrollert to ganger; høyst fem innsendinger; bare tydelig gjenkjente kontaktskjemaer uten obligatoriske personopplysninger; ingen domener til offentlige myndigheter, utdanningsinstitusjoner, klinikker, legepraksiser, politi eller domstoler; språkmodellen kan ikke frigi noe; testmelding uten personopplysninger, merket, med henvisning til søkerobotsiden og opt-out	R9	`scanner/src/worker.js`; `scanner/src/classify.js`; `scanner/src/active.js`
Nettleserforløp: bare GET og HEAD, farlige adresser blokkert, oppdiktede verdier forlater ikke nettleseren, bilder med svarte felt over inndatafeltene	R3 (for disse bildene), R9	`scanner/src/browser.js`
Filkontroll: bare bekreftede domener, én henting per sti, høyst 8 KB, innhold lagres aldri	R9	`cfg/dateien_lib.php`
Andre test: slått av som standard; ville bare motta en fast liste over ufarlige elementer, signert	Mottakere	`cfg/formular_probe_lib.php`
Skanning bak innloggingen: bare et bekreftet domene, betalt abonnement, eier eller administrator, bekreftelse på «testkonto»; kryptering med skanneserverens offentlige nøkkel, bundet til domenet; påloggingsopplysninger vises aldri, loggføres aldri og utleveres aldri via API-et; overlevering bare via standard inndata; feltet i jobben tømmes umiddelbart, rester etter én time; ingen skjermbilder, ingen innsendinger, ingen adresser for utlogging eller sletting, avbrudd ved CAPTCHA; endelig sletting med overskriving	R8	`cfg/login_lib.php`; `scanner/src/login.js`; `scanner/src/geheim.js`; `scanner/src/worker.js`
Leveringskontroll: slått av som standard; hentingen leser bare hodefelter og 8 KB, uten lesemerking; innhold og besøksadresse aldri i databasen; hver hentede e-post slettes, også dem som ikke kan tilordnes; tilordninger slettes etter 180 dager; dokumentasjon bare via kopien av akkurat denne testen	R1, R2	`cfg/zustellung_lib.php`
Svermbeskyttelse: bare domener, IP-nettverk av; minsteantall; unntak for store tjenester og Kundedomener; karantene i stedet for sletting; listen bygges opp på nytt daglig; rapporter slettes etter 30 dager	R11	`cfg/swarm_lib.php`
Språkmodell på egen server, uten rett til å sende inn	R10	`scanner/src/classify.js`
Tiltaksplan: lokal generering fra utvalgte funn, ingen skjermbilder eller innskrevne feltverdier i instruksen; begrenset antall funn og notatlengde; renset ren tekst med begrenset lengde; synlig KI-merknad, de enkelte funnene avgjørende; ingen automatiske endringer på nettstedet eller avgjørelser om poengsum/konklusjon	R10 delvis; feilaktige råd og tilfeldige personopplysninger er fortsatt mulig	`cfg/plan_lib.php`; `www/report.php`
Signaler via Telegram inneholder bare en fast setning uten variabler	Mottakere	`cfg/check_lib.php`
Ukentlig test av gjenoppretting fra sikkerhetskopien, med varsel ved feil	Tilgjengelighet	`cfg/backup_lib.php`; `srv/cron_status.php`

9.2 Delvis – på plass, men oppfyller ennå ikke formålet

Tiltak	Hvorfor det ennå ikke er fullt virksomt
«Rensede» skjermbilder	Bare bildene fra nettleserforløp sladdes. Søkerobotens bilder – startside og skjemaelementer – og bildet av svarsiden fra en aktiv kontroll sladdes ikke (R3).
Frister for kontrolldata	Virksomme for anonyme kontroller, kontroller for potensielle kunder og Kundekontroller; ikke for interne kontroller og upubliserte studier; uløste avviksnotater uten tidsgrense (R4).
Sletting av kontrollkopiene	Virksom i vårt innsyn i postkassen. Hvis kjøringen avbrytes, blir e-poster liggende; hva postkasseleverandøren beholder i egne sikkerhetskopier, er ikke verifisert (R2).
Beskyttelse av påloggingsopplysninger ved skanning bak innloggingen	Sterk i hvile og i kontrolltjenesten; ikke på vei til nettstedet: `http` er tillatt, sertifikatfeil ignoreres (R8).
Dokumentasjon på råderett	Kontrolleres én gang og gjelder deretter for alltid; vertsnavnet til et domene med dokumentert råderett kan imidlertid ikke endres, slik at dokumentasjonen ikke overføres til en annen vert (R7).
Informasjon til de registrerte	På plass for operatører via søkerobotsiden, identifikatoren, Personvernerklæringen og opt-out; for besøkende i leveringskontrollen avhengig av at Kunden tar i bruk tekstblokken; applikasjonen kontrollerer ikke dette.
Oppfordring til Kunder om ikke å la særlige kategorier inngå i kontrollkopien	Angitt i de juridiske dokumentene, men ikke teknisk understøttet: under oppsett spør applikasjonen ikke om nettstedstypen og advarer ikke om domener som ser ut til å gjelde helse, jus eller utdanning (R1).

9.3 Planlagt – ikke gjennomført

Tiltak	Håndterer	Prioritet
Slettingsforløp for interne kontroller: slett kontroller uten domene og uten rapport etter en fast frist (forslag: 30 dager); slett rådataene fra en studie senest en fast tid etter avslutningen, også uten publisering (forslag: 90 dager); slett de eksisterende 85 kontrollene med 369 bilder én gang	R4	Først
Aktiver leveringskontrollen først når avtalen med postkasseleverandøren er inngått, lagringssteder, underdatabehandlere og sikkerhetskopifrister er dokumentert, overføringsmekanismen for postkasseleverandøren er avklart, og MX-oppføringene til domenet vårt peker direkte til postkassen; hold funksjonen sperret i produksjonssystemet frem til da	R2	Først
Kontroller og dokumenter sikkerheten ved postkassehentingen på produksjonssystemet før leveringskontrollen aktiveres	R2	Først
Skanning bak innloggingen bare via `https` og med gyldig sertifikat; avvis `http`-adresser; sertifikatfeil ved innlogging som grunn til avbrudd	R8	Først
Ikke lagre verdier i skjulte felt bak innloggingen (bare navn, type og lengde) – allerede gjennomført slik, ingen ytterligere tiltak	R8	Ferdig
Begrens kontrollkopien til testmeldinger der programtillegget eller utvidelsen er i bruk: blindkopi bare for innsendinger med testidentifikatoren vår	R1	Høy
Ikke lagre avsenderdomenet til ekte meldinger eller skriv det i varsler hvis det verken er nettstedets domene eller domenet til en kjent avsendingstjeneste; bruk i stedet «fremmed avsenderdomene» i varselet	R1	Høy
Advarsel ved oppsett av leveringskontrollen for domener som ser ut til å gjelde helse, jus, sosialtjenester eller utdanning, med henvisning til Kundens egen vurdering av personvernkonsekvenser	R1	Høy
Forny dokumentasjon på råderett regelmessig (forslag: kontroller før hver aktiv kontroll om DNS-oppføringen, metataggen, filen eller programtilleggsforbindelsen fortsatt finnes; fortsett ellers passivt og varsle Kunden)	R7	Høy
Slutt å ta bilde av startsiden, eller gjør det bare med sladdede bilder og ansikter; begrens skjemabilder til skjemaelementet (som i dag) og masker inndatafelt som ved nettleserforløp	R3	Høy
Merknad i grensesnittet for kontroll av potensielle kunder: å sende det korte funnet uanmodet via e-post eller telefon er direkte markedsføring også mellom virksomheter og krever forhåndssamtykke (art. 398 i den polske loven om elektronisk kommunikasjon; i Tyskland § 7(2) UWG, men antatt samtykke er tilstrekkelig for telefonsamtaler til virksomheter)	R6	Høy
Infrastruktur: fullfør herdingen av serveradministrasjonen; kryptert sikkerhetskopi på et annet sted; krypter forbindelser i det interne nettverket gjennomgående; styrk skillet mellom skanneserveren og applikasjonen ytterligere	R13	Høy
Frist for uløste avviksnotater (forslag: løsning innen 30 dager, ellers sletting av IP-adressen)	R4	Middels
En side eller et skjema der noen kan be om at et domene fjernes fra svermbeskyttelsen	R11, R14	Middels
Før IP-nettverk slås på i svermbeskyttelsen: en ny versjon av denne vurderingen	R11	Vilkår
Registrer om språkmodellprogramvaren lagrer forespørsler, og slå i så fall av disse loggene	R10	Lav

9.4 Prosedyrer og beslutninger som fortsatt må fastsettes

I tillegg til tekniske sikkerhetstiltak krever art. 35(7)(d) også prosedyrer. Disse gjenstår fortsatt:

Brudd på personopplysningssikkerheten. Oppdagelse: eieren, applikasjonens feilvarsel, meldinger via mottaksstedet for sårbarhetsmeldinger eller contact@lukaswojcik.com. Beslutning om melding til UODO innen 72 timer (art. 33(1)): eieren. Informasjon til berørte Kunder som behandlingsansvarlige: uten ugrunnet opphold, om mulig innen 48 timer, som lovet i Databehandleravtalen. Må fastsettes: en skriftlig prosedyrebeskrivelse og en første øvelse; for leveringskontrollen i tillegg hvordan det skal fastslås hvilke Kunder som berøres av et brudd hos postkasseleverandøren.
Sektorer. Må fastsettes: om leveringskontrollen tilbys, tilbys med advarsel eller utelukkes for nettsteder innen helse, jus, sosialtjenester og utdanning.
Interne kontroller. Må fastsettes: hva leverandøren bruker interne kontroller fra kommandolinjen til, hvem som kan opprette dem og hvor lenge resultatene beholdes; og om de, utover Protokoll over behandlingsaktiviteter, må omtales i Personvernerklæringen.
Studier. Må fastsettes: hvem som setter sammen lister, fra hvilke kilder, med hvilken maksimal størrelse, og en kontroll før hver studie av om den samsvarer med forutsetningene i denne vurderingen.
De registrertes synspunkter (art. 35(9)). De er ikke innhentet for denne versjonen. Art. 35(9) krever at de innhentes bare «dersom det er relevant»; etter vår vurdering er det for tiden ikke tilfellet her. Operatører av kontrollerte nettsteder og besøkende på Kundenes nettsteder har ingen egen kanal til oss; å henvende seg særskilt til dem ville i seg selv være en ny behandling av opplysningene deres, og tjenesten er ennå ikke lansert, så det finnes foreløpig ingen gruppe av faktiske registrerte. Interessene deres tas indirekte i betraktning: gjennom robots.txt og opt-out, gjennom de korte fristene og gjennom at innholdet i kontrollkopier ikke lagres. Ved hver gjennomgang etter avsnitt 12 vurderer vi på nytt om det er relevant å innhente synspunktene deres, for eksempel via tilbakemeldinger på søkerobotsiden eller fra Kunder av leveringskontrollen.

10. Gjenværende risiko og forhåndsdrøftinger etter art. 36

Art. 36(1) krever forhåndsdrøftinger med tilsynsmyndigheten når vurderingen av personvernkonsekvenser viser at behandlingen ville medføre høy risiko dersom den behandlingsansvarlige ikke treffer tiltak for å redusere risikoen. Spørsmålet er derfor ikke om høye risikoer ble identifisert – det ble fire – men om det gjenstår en høy risiko når tiltakene er på plass.

For behandlingsaktivitetene der formexposed er behandlingsansvarlig (P1 til P4, P7), kan de høye risikoene R4 og R13 avhjelpes med vanlige midler: et slettingsforløp og opprydding i de eksisterende opplysningene, en kryptert sikkerhetskopi på et annet sted og herding av to servere. Med tiltakene fra 9.3 faller de til lavt til middels nivå. R3, R5, R6 og R7 ligger på middels nivå og faller til lavt nivå med de foreslåtte tiltakene. Svermbeskyttelse uten IP-nettverk forblir på lavt til middels nivå. Forhåndsdrøftinger er ikke påkrevd for denne delen hvis tiltakene merket «først» og «høy» gjennomføres før lansering. Hvis noen av disse tiltakene ikke er gjennomført før lansering, gjenstår en høy risiko for den berørte behandlingsaktiviteten. Den behandlingsaktiviteten vil da først bli startet når tiltaket er gjennomført, eller UODO vil først bli rådspurt etter art. 36(1).

For leveringskontrollen (P6) er situasjonen annerledes, av en grunn som ingen tiltak helt fjerner: hva en besøkende skriver, bestemmer vedkommende selv. Med inngått avtale, sikret henting, begrensning til testmeldinger der det er mulig, og uten avsenderdomenet, faller R2 til lavt nivå og R1 til middels. For Kunder der besøkende vanligvis oppgir opplysninger etter art. 9, kan R1 likevel forbli høy. Plikten til forhåndsdrøftinger ligger da hos Kunden som behandlingsansvarlig, ikke hos formexposed. Vår anbefaling til slike Kunder er å ikke konfigurere kontrollkopien for det generelle kontaktskjemaet, men bare for skjemaer uten sensitivt innhold, eller å avstå fra leveringskontrollen.

Gjenværende risiko, ærlig angitt. I dag, med tiltakene fra 9.1, ligger fire risikoer på høyt nivå: R1 og R2 (leveringskontroll), R4 (kontrolldata uten slettingsforløp) og R13 (infrastruktur). Med tiltakene fra 9.3 faller R2, R4 og R13 til lavt til middels nivå. R1 forblir på middels nivå og er varig avhengig av beslutninger Kundene treffer. Ingen av de andre risikoene ligger over middels nivå etter tiltakene.

Art. 36 er ingen straff, og forhåndsdrøftinger er ingen innrømmelse. Det er fremgangsmåten forordningen angir for situasjonen der en nyttig prosedyre medfører en risiko den behandlingsansvarlige ikke fullt ut kontrollerer. En Kunde som vil bruke leveringskontrollen for meldinger som inneholder helseopplysninger, finner faktaene for denne beslutningen her.

11. Hva Kunder trenger for sin egen vurdering av personvernkonsekvenser (art. 28(3)(f))

For leveringskontrollen og skanningen bak innloggingen er Kunden behandlingsansvarlig. Denne siden gir Kunden beskrivelsen (avsnitt 6.5 og 6.6), risikoene fra vårt perspektiv (R1, R2, R8) og statusen til tiltakene (avsnitt 9). Bare Kunden kan besvare følgende spørsmål:

Hva skriver de besøkende mine? Må det forventes at opplysninger om helse, religion, opprinnelse, fagforeningsmedlemskap, seksuell orientering, straffbare forhold eller barn kommer inn via skjemaet? Da kreves som regel en vurdering av personvernkonsekvenser for kontrollkopien, og kontrollkopien for dette skjemaet bør vurderes på nytt.
Trenger jeg kontrollkopien for alle meldinger? For å dokumentere at testmeldingen vår kommer frem, er det tilstrekkelig for den meldingen. Der skjemaet tillater det, konfigurer blindkopien bare for testmeldinger.
Hvordan informerer jeg de besøkende mine? Databehandleravtalen krever det; Personverntekst for nettstedet ditt beskriver kopiens forløp og rollen vår.
Hvilket rettslig grunnlag har jeg? Tekstforslaget vårt oppgir art. 6(1)(f) (pålitelig mottak av henvendelser). For opplysninger etter art. 9 er dette grunnlaget alene ikke tilstrekkelig.
Hvilke varslingskanaler velger jeg? Varsler fra autentisitetskontrollen kan navngi avsenderdomenet. Den som sender varsler til chattetjenester utenfor EU, overfører det dit.
For skanningen bak innloggingen: Er testkontoen virkelig en testkonto med de minste nødvendige rettighetene? Kan innloggingssiden bare nås via https? Ser testkontoen opplysninger om andre brukere? Hvis ja: på hvilke av de angitte sidene?
Når sletter jeg? Leveringskontrollen og testkontoen kan når som helst slås av og slettes; testkontoen overskrives da permanent.

Ytterligere dokumenter for Kundens vurdering: Databehandleravtale, Tekniske og organisatoriske tiltak, listen over Underdatabehandlere og Protokoll over behandlingsaktiviteter. Vi besvarer spørsmål om enkelte fakta på contact@lukaswojcik.com.

12. Gjennomgang, versjon og godkjenning

Art. 35(11) krever en gjennomgang for å vurdere om behandlingen utføres i samsvar med vurderingen av personvernkonsekvenser, i det minste når risikoen endrer seg. Vi gjennomgår denne vurderingen minst årlig og også før hver av følgende hendelser; hver utløser en ny måling, ikke bare en gjennomlesing:

lansering av produksjonsdriften, med tall fra produksjonssystemet i stedet for utviklingssystemet;
første aktivering av leveringskontrollen på produksjonssystemet og inngåelse av avtalen med postkasseleverandøren;
aktivering av IP-nettverk i svermbeskyttelsen;
den første studien, og hver studie med en større liste enn den forrige;
aktivering av den andre testen eller en ny mottaker i kontrollforløpet;
enhver ny bruk av språkmodellen som går utover bruksområdene denne vurderingen omfatter; den prioriterte tiltaksplanen i betalte rapporter er et nytt bruksområde og krever at vurderingen gjennomgås;
enhver endring i skjermbildene, fristene eller forutsetningene for aktive kontroller.

Punkt	Oppføring
Behandlingsansvarlig	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland · NIP 7252266190 · contact@lukaswojcik.com
Vedkommende tilsynsmyndighet	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Poland
Personvernombud	Ikke utpekt; vurdering etter art. 37 i avsnitt 4
Faktagrunnlag	Kildekode til applikasjonen og kontrolltjenesten, databaseskjema, radantall og innstillinger i utviklingssystemet, målt 11. oktober 2026, skrivebeskyttet tilgang
Tilknyttede dokumenter	Personvernerklæring, Databehandleravtale, Tekniske og organisatoriske tiltak, Underdatabehandlere, Protokoll over behandlingsaktiviteter, EUs KI-forordning, Akseptabel bruk og misbruk, FormExposedBot, Opt-out
Versjon	1.1 av 23. oktober 2026; faktatillegg om det lokale tiltaksplantrinnet til den første versjonen av 11. oktober 2026
Gjennomganger etter art. 35(11)	23. oktober 2026: kildekodegjennomgang av det nye lokale tiltaksplantrinnet. Inndata, lagring, roller, veiledende utdata og gjennomførte sikkerhetstiltak er lagt til i de tilsvarende avsnittene; det hevdes ikke at en produksjonsmåling er fullført eller at en ny vurdering av gjenværende risiko er gjort. De tidligere målingene datert 11. oktober 2026 og godkjenningsstatusen nedenfor er uendret. Ytterligere gjennomganger føres inn her med dato, grunn og resultat.
Godkjenning	Ennå ikke godkjent. Godkjenning av eieren etter juridisk gjennomgang og etter en beslutning om tiltakene fra avsnitt 9.3 og spørsmålene fra avsnitt 9.4. Ekstern personvernrådgivning er hittil ikke innhentet.

En avsluttende betraktning hører hjemme i dokumentet og ikke i et følgebrev. De delene av formexposed som griper lengst inn i andres domener – testinnsendingene og innloggingen med andres påloggingsopplysninger – er bygget med størst varsomhet: to sperrer, faste øvre grenser, kryptering som stenger selv oss ute. Risikoene i denne vurderingen ligger for det meste andre steder: i det som følger med tilfeldig – ekte meldinger i en blindkopi, personer i et skjermbilde, kontroller som ingen lenger sletter. Det er et gunstig utgangspunkt, fordi det tilfeldige kan stoppes uten å endre tjenesten.

Hvordan kan vi hjelpe?