Protokoll over behandlingsaktiviteter (personvernforordningen art. 30)

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

Versjon 1.2 · Sist oppdatert: 29. oktober 2026

1. Slik leser du denne protokollen

Dette er protokollen over behandlingsaktiviteter etter personvernforordningen art. 30 for formexposed. Den er ikke en personvernerklæring og ikke markedsføring. Oppgaven er å vise en tilsynsmyndighet, en Kunde som reviderer oss som databehandler, eller den neste personen som må besvare et spørsmål, hva som faktisk behandles, hvor det oppbevares, hvem som mottar det og hvor lenge det beholdes. Vi publiserer den fordi en tjeneste som kontrollerer og overvåker skjemaer, selv bør være åpen for kontroll.

Tre regler styrte utarbeidelsen.

1. Målt, ikke planlagt. Et utsagn om datafelt, lagringstider, mottakere eller beskyttelsestiltak tas bare med der programkoden, databaseskjemaet eller en måling underbygger det. Det som er planlagt, kalles «planlagt». Det som er slått av som standard, kalles «av som standard». Der vi ikke kan dokumentere noe, sier vi det.
2. Lagring oppgis to ganger. Én gang for hver behandlingsaktivitet og én gang i punkt 6 som et samlet bilde: Hvilken nattlig kjøring sletter hvilke opplysninger, og hvilke opplysninger den ikke når. En protokoll som hevder en lagringstid som bare gjelder en del av opplysningene, er verre enn en som navngir det åpne spørsmålet.
3. Åpne spørsmål oppgis i teksten, ikke i en fotnote. Punkt 8.1 lister tiltak som ennå ikke er gjennomført, punkt 10 de åpne spørsmålene med planlagte tiltak. En protokoll er et arbeidsverktøy, ikke et sertifikat.

Datafelt i stedet for tabellnavn. For hver behandlingsaktivitet oppgir vi de lagrede opplysningene som felt i klart språk. Navnet på databasetabellen følger i parentes, slik at en revisor kan finne stedet, for eksempel «innloggingsforsøk (login_attempts)». Feltlistene er utledet fra databaseskjemaet, ikke fra hukommelsen.

Lagringstider som plassholdere. Der en lagringstid kan stilles inn i administrasjonsområdet, vises den her nøyaktig slik den nattlige kjøringen leser den: Tallet du ser, kommer fra den samme innstillingen som styrer slettingen. Lagringstider som er fastsatt i programmet, oppgis som tall.

Målegrunnlag. Skjema, kode og innstillinger ble målt 11. oktober 2026 på utviklingssystemet, som samsvarer med produksjonssystemet i kode og skjema. Vi oppgir ikke antall rader fra utviklingssystemet; de inneholder testdata og sier ingenting om produksjonsdriften.

Bevisst utelatt. Denne protokollen oppgir ikke vertsnavn, interne nettverksadresser, porter, brukernavn eller programvareversjoner for serverne våre. Slike detaljer hjelper en angriper og ingen registrert. Av samme grunn beskriver vi åpne spørsmål om sikringen av våre egne servere bare i generelle vendinger (punkt 8.1): Vi navngir risikoen, ikke veien til den. Vi gir detaljene til en tilsynsmyndighet på forespørsel.

Rettslig karakter. Denne protokollen er dokumentasjonen vi fører etter personvernforordningen art. 30 for tilsynsmyndigheten; den publiseres frivillig. Den er ikke en del av noen avtale og utgjør ingen tilsikring, garanti eller kvalitetsavtale overfor Kunder eller tredjeparter. Hva vi er forpliktet til å levere Kundene, reguleres av Bruksvilkårene, Databehandleravtalen og vedleggene; for disse pliktene har de forrang fremfor denne protokollen. Protokollen beskriver stillingen på datoen for denne versjonen. Klassifiseringer som «åpent spørsmål» eller «vurdering» gjenspeiler vårt eget syn og foregriper ingen rettslig vurdering fra en tilsynsmyndighet eller domstol; tiltak beskrevet som «planlagt» er hensikter uten en forpliktende dato.

2. Rettsubjektet og hvorfor denne protokollen har to halvdeler

Felt	Oppføring
Rettsubjekt	LW IT Solutions Company Lukas Wójcik, enkeltpersonforetak registrert i det polske næringsregisteret (CEIDG); eier Lukas Wójcik
Adresse	al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen
Skatteidentifikatorer	NIP 7252266190, merverdiavgiftsnummer PL7252266190
Kontakt	contact@lukaswojcik.com; kundestøttevinduet (spørsmålstegn i navigasjonen); kontaktsiden
Tjeneste	formexposed: kontroll, overvåking og sikring av kontaktskjemaer på nettsteder (applikasjon på formexposed.com, landingsside på form.exposed)
Representant etter personvernforordningen art. 27	Ikke relevant. Rettsubjektet er etablert i Unionen (Polen).
Personvernombud	Ikke utpekt. Vurderingen etter art. 37 står i punkt 9.
Ansvarlig tilsynsmyndighet	Prezes Urzędu Ochrony Danych Osobowych (UODO, den polske personvernmyndigheten), ul. Moniuszki 1A, 00-014 Warszawa
Hosting	Våre egne servere i Polen: én nettserver med applikasjonen og databasen og én skanneserver med en lokal språkmodell i samme interne nettverk. Ingen tredjeparts datasenter- eller skyleverandør.

formexposed har ulike roller overfor ulike grupper av mennesker. Å blande dem sammen gir en protokoll som ikke er riktig for noen av dem.

• Behandlingsansvarlig (del B, art. 30(1)). Vi er selv behandlingsansvarlig for opplysningene om våre egne Kunder og teammedlemmene deres (konto, innlogging, fakturering, kundestøtte, logger), for besøkende på vårt eget nettsted, for kontroller uten konto (gratis kontroll, verktøy for HTTP-hoder, studie, kontroll av potensielle kunder) og for forebygging av misbruk.
• Databehandler (del A, art. 30(2)). For personopplysninger om tredjeparter som en Kunde bringer inn i tjenesten, eller som oppstår når vi utfører en tjeneste for Kunden, handler vi på Kundens vegne: kopier av reelle skjema-e-poster i leveringskontrollen, abonnenter i Kundens kundeportal, mottakere av Kundens varsler, personer som tilfeldigvis er synlige på Kundens kontrollerte sider, innloggingsopplysningene til Kundens testkonto og skjemakoden Kunden limer inn. Grunnlaget er Databehandleravtalen, som inngås med hver Kunde ved registrering.
• Bare på Kundens side. Noen funksjoner i WordPress-tillegget og TYPO3-utvidelsen behandler opplysninger utelukkende på Kundens nettsted, uten at opplysningene noen gang når oss (karantene, sikkerhetsnett, regneoppgave, lagringsinnstillinger, lokale tellere, opptaker). De er ikke behandling utført av oss og vises derfor ikke i noen av delene. Vi beskriver dem likevel på slutten av del A slik at grensen er synlig.

Atskillelsen er bygget inn i koden, ikke bare i teksten: Fra en reell skjema-e-post skriver leveringskontrollen bare tidspunktet, tilordningen og autentiseringsresultatet til databasen; skjermbildene fra nettleserkontrollene maskerer inndatafelt; testkontoens innloggingsopplysninger krypteres slik at nettserveren ikke lenger kan lese dem. Detaljene finnes i oppføringene.

Punkt 6 til 11 gjelder begge halvdelene: lagring, automatiserte avgjørelser, tekniske og organisatoriske tiltak, personvernombud, åpne spørsmål og vedlikeholdet av denne protokollen.

Virkeområde. Dette dokumentet er den delen av protokollen som gjelder tjenesten formexposed. Behandling utført av samme rettssubjekt for andre tjenester registreres i egne protokoller; generell regnskapsføring og virksomhetsadministrasjon utenfor tjenesten omfattes ikke av denne delen.

3. Del A – art. 30(2): behandling på vegne av Kunder

A.0 Involverte parter

Felt	Oppføring
Databehandler	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen; contact@lukaswojcik.com
Behandlingsansvarlige	Kundene til formexposed: næringsdrivende og byråer som har domener i kontoen sin og bruker funksjoner der tredjepartsopplysninger oppstår. For byråer kan byråets egen kunde i tillegg være behandlingsansvarlig; byrået handler da som databehandler overfor denne kunden, og vi som en ytterligere databehandler.
Liste over behandlingsansvarlige	En del av denne protokollen, ført elektronisk (personvernforordningen art. 30(3)) i tjenestens system og ikke gjengitt i denne offentlige versjonen, fordi den inneholder Kundenes personopplysninger og ville bli utdatert med hver ny Kunde: eieren av hvert arbeidsområde med navn, e-postadresse og firma fra kundekontoen (adresse og merverdiavgiftsnummer bare hos Stripe) (users, workspaces, workspace_users), pluss arbeidsområdets domener (domains). Vi gir et utdrag til en tilsynsmyndighet på forespørsel.
Representanter og personvernombud for de behandlingsansvarlige	Det finnes ikke noe eget felt for dette i systemet. Hvis en Kunde har utpekt en representant etter personvernforordningen art. 27 eller et personvernombud, kan Kunden melde dem til oss; vi oppbevarer meldingen sammen med listen over behandlingsansvarlige.
Databehandlerens representant	Ikke relevant (etablert i Polen).
Personvernombud	Ikke utpekt (punkt 9).
Instrukser	Instruksen følger av Databehandleravtalen og innstillingene Kunden gjør: Kunden slår på leveringskontrollen, setter opp varslingsmottakere, lagrer en testkonto og setter opp en kundeportal. Uten denne handlingen skjer ikke den aktuelle behandlingen.
Tekniske og organisatoriske tiltak	Punkt 8 og siden Tekniske og organisatoriske tiltak gjelder alle behandlingsaktiviteter i del A. Særlige tiltak oppgis i den aktuelle oppføringen.

A.1 Leveringskontroll – kontrollkopi av skjema-e-poster

Felt	Oppføring
Formål	Å kontrollere om e-posten fra Kundens kontaktskjema faktisk sendes, og hvordan den autentiseres (SPF, DKIM, DMARC, samsvar). Etter en godtatt aktiv testinnsending må kopien komme frem til kontrollpostkassen innen en justerbar ventetid (for tiden 3 timer); ellers utløses varselet «Test-e-post ikke mottatt». Hodene brukes også til å utlede autentisiteten til skjema-e-posten, e-posttjenesten som brukes og avsenderadressen for kontroll mot blokkeringslister.
Forutsetning	Betalt abonnement, verifisert domene, slått på av Kunden. Kunden legger inn sin egen kontrolladresse med en identifikator (på formen «delivery+identifier@…») som blindkopi i skjemavarslingen. Uten en konfigurert kontrollpostkasse er funksjonen ikke tilgjengelig.
Kategorier av registrerte	Besøkende på Kundens nettsted som sender inn Kundens skjema; personer hvis opplysninger en besøkende skriver i meldingen; Kundens ansatte som står som mottakere i hodene.
Kategorier av personopplysninger	I kontrollpostkassen (hos e-postleverandøren): den fullstendige kopien av hver skjema-e-post, inkludert reelle henvendelser med navn, e-postadresse, telefonnummer og fritekst, frem til sletting. Lest ved henting: hodene og høyst de første 8 KB av meldingsteksten. I databasen: mottakstidspunkt, tilordning til domenet og eventuelt testkjøringen (delivery_log); det siste autentiseringsresultatet per domene med SPF-, DKIM- og DMARC-resultat, samsvar, avsenderdomene, signeringsdomener og adressen til avsenderserveren for e-post (domenets autentiseringsfelt i domains). Innhold, emne og den besøkendes avsenderadresse skrives ikke til databasen.
Merknad om avsenderdomenet	Hvis et skjema bruker den besøkendes adresse som avsender (en feilkonfigurasjon kontrollen er laget for å avdekke), inneholder autentiseringsresultatet domenet til denne adressen, ikke selve adressen. Der en besøkende bruker et personlig domene, kan også dette være en personopplysning. Det overskrives ved neste mottak.
Kilde	Skjemaet på Kundens nettsted, via blindkopien Kunden har lagt inn.
Rettslig grunnlag (fastsatt av den behandlingsansvarlige)	Fastsettes av Kunden. Tekstforslaget vårt til Kundens personvernerklæring bygger kopien på personvernforordningen art. 6(1)(f) (berettiget interesse i å motta henvendelser pålitelig). Kunden informerer de besøkende om denne dataflyten; Databehandleravtalen forplikter Kunden til dette.
Mottakere	E-postleverandøren som driver kontrollpostkassen (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). Kopien går direkte dit: Den kommer bare frem hvis MX-oppføringene til domenet vårt peker til denne postkassen (sjekklisten før lansering kontrollerer dette); via videresending når den ikke postkassen. På domenesiden ser Kunden bare tidspunkt, tilordning og autentiseringsresultat. Hvis autentiseringsresultatet forverres, navngir varselet til Kunden og de valgte kanalene avsenderdomenet hvis det ikke tilhører nettstedet (A.3, 4.1).
Tredjeland	Avhenger av e-postleverandøren; se punkt 4. Avtalen med den tiltenkte leverandøren og overføringsgrunnlaget er ennå ikke dokumentert.
Lagring	Etter vellykket behandling merkes e-posten for sletting og fjernes fra postkassen i samme kjøring, også hvis den ikke kan tilordnes noe domene. Henting kjører sammen med statuskjøringen hvert femte minutt mens overvåking er slått på i administrasjonsområdet (srv/cron_status.php, cfg/zustellung_lib.php). Hvis henting eller sletting mislykkes, forblir e-posten i postkassen frem til neste vellykkede kjøring. Den samme hentingen sletter tilordningene i delivery_log etter 180 dager. Autentiseringsresultatet finnes så lenge domenet finnes.
Hva dokumentasjonen beviser	Bare mottaket i kontrollpostkassen av kopien som er tilordnet den konkrete testkjøringen. Den beviser verken mottak hos den faktiske mottakeren eller en oppføring i CRM-et. Innebygd bekreftelse fra HubSpot tilbys ikke.
Tekniske og organisatoriske tiltak	Punkt 8. Særlig: Innhold vurderes bare i minnet; ingen lagring av meldingstekst, emne eller fullstendige avsenderadresser; sletting uavhengig av om tilordningen lyktes.

Leveringskontrollen er den eneste funksjonen der reelle meldinger fra Kundenes besøkende når oss. Derfor er den behandling på vegne av Kunden og ikke en tjeneste under vårt eget ansvar, og derfor er tiden i postkassen det reelle risikomålet: normalt minutter; hvis hentingen er forstyrret, frem til den kjører igjen. Kopier bør ikke inneholde særlige kategorier av personopplysninger; vi kan ikke forhindre dette teknisk, fordi det er opp til den besøkende hva som skrives.

A.2 Kundeportal og månedsrapport til abonnenter

Felt	Oppføring
Formål	Et byrå (Business-abonnement) viser kundene tilstanden til domenene deres under egen merkevare (portal på en tilfeldig adresse, eventuelt med passord, eventuelt under byråets eget underdomene). Kunden kan der bestille en månedsrapport per e-post. Rapporten sendes i byråets navn.
Kategorier av registrerte	Byråets kunder og deres ansatte som bestiller rapporten; personer som åpner portalen.
Kategorier av personopplysninger	Abonnent: e-postadresse, språk, bekreftelsesidentifikator, tidspunkt for bestillingen og IP-adresse ved bestilling, tidspunkt for bekreftelse (dobbel bekreftelse), tidspunkt for avmelding, siste måned sendt (client_subscribers). Portal: navn, utvalg av domener, tilfeldig identifikator, passord bare som en hash, personen som opprettet den, tidspunkt, tilbakekalling (client_portals). Besøk i portalen vises i sidevisningsloggen (B.2).
Kilde	Oppgis av abonnentene selv i portalen.
Rettslig grunnlag (fastsatt av den behandlingsansvarlige)	Abonnentens samtykke, innhentet gjennom en prosedyre med dobbel bekreftelse; behandlingsansvarlig er byrået. Vi skriver ikke til noen som ikke selv har meldt seg på og bekreftet påmeldingen.
Mottakere	Byrået (ser abonnentene sine); e-postleverandøren (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) for bekreftelses-e-posten og rapporten.
Tredjeland	Via e-postleverandøren; se punkt 4.
Lagring	Nattlig slettekjøring (cfg/fristen_lib.php, delen «portalabonnenter»): bestillinger som aldri er bekreftet, etter 30 dager; avmeldte abonnenter tre år etter avmelding, som dokumentasjon på det tidligere samtykket. Bekreftede abonnenter som ikke har meldt seg av, beholdes så lenge byråets arbeidsområde finnes. En tilbakekalt portal sperres bare, den slettes ikke; abonnentene mottar ikke lenger rapporter, men opplysningene deres beholdes (punkt 10). Portaler og abonnenter forsvinner umiddelbart med arbeidsområdet (fe_arbeitsbereich_daten_loeschen()). Sendte rapporter forblir i utboksen i 30 dager (B.25).
Tekniske og organisatoriske tiltak	Punkt 8. Særlig: Portalpassord bare som en hash, gjettingsforsøk begrenset (ti per portal og IP-adresse, 50 per portal på 15 minutter); avmelding med ett klikk i hver e-post; portalen viser bare status og nøkkeltall, ingen enkeltfunn med dokumentasjon.

A.3 Kundens varslingsmottakere, bekreftende personer og ansvarlige

Felt	Oppføring
Formål	Varslinger om feil og endringer til mottakerne Kunden setter opp for et domene: e-post, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Per mottaker umiddelbart eller samlet daglig eller ukentlig, i tillegg mottakere bare for eskaleringer. Hver problemmelding blir en hendelse som mottakeren kan bekrefte via en lenke. For overvåkede skjemaer kan Kunden angi en ansvarlig person og en frist.
Kategorier av registrerte	Kundens ansatte og tjenesteleverandører som Kunden oppgir som varslingsmottakere eller ansvarlige; personer som bekrefter en hendelse. Teammedlemmer med egen konto vises også i del B.
Kategorier av personopplysninger	Varslingsmottaker: kanal, mottakeradresse (e-postadresse, webhook- eller chatadresse, Telegram-chat-ID), valgte hendelser, leveringsmåte, signeringshemmelighet for webhooks, siste levering og siste feil (alerts). Leveringslogg: mottaker, hendelser, status, feil, tidspunkt (alert_log). Sammendragskø: varslingslinjer og lenke frem til levering (alert_queue). Hendelse: tittel, varslingslinjer, lenke, bekreftelsesidentifikator, tidspunkt og navn eller e-postadresse til personen som bekrefter, som oppgitt i skjemaet, ellers adressen til det innloggede medlemmet (alert_incidents). Leveringsforsøk ved eskalering per hendelse og mottaker: antall forsøk (høyst fem), tidspunktene for siste og neste forsøk og vellykket levering, henvisning til e-posten i utboksen, feil (tabell alert_escalation_deliveries). Tilordning: kontoen til den ansvarlige personen og frist (i monitored_forms).
Varslingenes innhold	Domene, hendelse, en kort forklaring og en lenke til domenesiden. Intet innhold fra besøkendes meldinger.
Kilde	Oppgitt av Kunden; personen som bekrefter, oppgir selv navnet sitt; Telegram-chat-ID-en opprettes når mottakeren trykker «Start» i boten (B.32).
Rettslig grunnlag (fastsatt av den behandlingsansvarlige)	Fastsettes av Kunden; som regel organiseringen av Kundens egen drift (personvernforordningen art. 6(1)(b) eller (f) i forhold til Kundens ansatte og tjenesteleverandører).
Mottakere	Operatørene av de valgte kanalene; se 4.1. E-postvarsler via e-postleverandøren (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Tredjeland	Avhengig av valgt kanal; flere leverandører holder til i USA, Telegram utenfor EU uten beslutning om tilstrekkelig beskyttelsesnivå. Se 4.1.
Lagring	Leveringslogg etter 90 dager (nattlig, fe_alert_log_aufraeumen() fra srv/cron_status.php). Sammendragsvarslinger 30 dager etter levering (cfg/kanal_lib.php, ved hver levering av sammendrag). Hendelser så lenge de er uløste; løste hendelser 180 dager etter løsning (cfg/vorfall_lib.php, eskaleringskjøring), sammen med leveringsforsøkene ved eskalering. Varslingsmottakere og tilordninger frem til Kunden sletter dem eller sammen med domenet.
Tekniske og organisatoriske tiltak	Punkt 8. Særlig: Webhooks signert med en separat hemmelighet per mottaker; bekreftelse bare etter et klikk (POST), slik at lenkeforhåndsvisninger i chatprogrammer ikke utløser noe; varsler under et vedlikeholdsvindu logges bare, de sendes ikke.

A.4 Personer som tilfeldigvis er synlige på kontrollerte Kundesider og i skjermbilder

Felt	Oppføring
Formål	Kontroll av domenene i Kundens konto (skanning, overvåking, aktiv kontroll) leser Kundens offentlige sider og tar skjermbilder av skjemaer. Det siden selv viser, kan gjelde personer som ikke har noe med kontrollen å gjøre. Disse opplysningene oppstår tilfeldig; de er ikke formålet med kontrollen.
Kategorier av registrerte	Personer som har navn, bilde eller kontaktopplysninger på den kontrollerte siden (kontaktperson ved skjemaet, teambilder på startsiden, leverandøropplysninger).
Kategorier av personopplysninger	Skjermbilder: det synlige området på startsiden, hvert synlige skjema som et utsnitt og bildet av siden som følger etter en aktiv testinnsending; lagres som filer utenfor nettkatalogen, med bare henvisningen i databasen (scan_screenshots). Skjemastruktur: sideadresse, selektor, feltnavn, felttyper, feltetiketter, markeringer for obligatoriske felt og synlighet, etiketter på sendeknapper (forms, feltet «feltkart»); ingen feltverdier. Skanneren leser begynnelsen av skjulte felt (inntil 24 tegn) og dataattributter (inntil 60 tegn) bare under kontrollen for å gjenkjenne tidsstempler og tokener; bare resultatet lagres. Funn med dokumentasjon (findings), sammendrag med sidetitler (scans). For kvalifiserte kontroller i betalte kontoer genererer en lokal modell en prioritert tiltaksplan fra utvalgte funn og skannemetadata; tekst, språk, status og tidsstempel lagres i skannesammendraget. Hvis en e-postadresse vises i skjemaet som mottaker, lagres bare domenet, aldri adressen.
Kilde	De offentlige sidene på Kundens domene, hentet av skanneren.
Rettslig grunnlag (fastsatt av den behandlingsansvarlige)	Fastsettes av Kunden for innholdet på Kundens eget nettsted. For oss er behandlingen en del av den bestilte kontrollen.
Mottakere	Kunden; for byråer deres kunde via portalen eller en rapport med egen merkevare; alle som mottar en rapportlenke (rapporter på tilfeldige adresser, ikke i søkemotorer). Der skjematypen er uklar, mottar en lokal språkmodell på vår egen server skjemastrukturen med sidetittel, sideadresse og skjemaets synlige tekst (inntil 400 tegn) for klassifisering; den mottar ikke bilder. For kvalifiserte betalte kontroller mottar den lokale modellen også vertsnavnet, det samlede resultatet og poengsummen, CMS-et, relevant skjematype og sideadresse, eventuelle identifiserte tillegg og utvalgte mislykkede eller uklare funn for å lage en tiltaksplan. Forespørselen beholdes midlertidig i den interne jobbkøen og slettes etter henting eller ved planlagt opprydding av oppføringer som er mer enn én time gamle.
Tredjeland	Ingen.
Lagring	Kontrollresultater for et domene i høyst 13 måneder; den siste fullførte kontrollen per domene beholdes (nattlig slettekjøring, delen «gamle kontrollresultater»). Skjemaer, funn, bildehenvisninger og bildefilene forsvinner med kontrollresultatet. Med domenet forsvinner disse opplysningene umiddelbart (slettekjede i B.15; unntak i punkt 6.4).
Maskeringens grenser	Skjermbildene fra den fullstendige kontrollen maskerer ingenting: De viser det siden viser enhver besøkende. Skjemafelt er tomme ved henting fordi skanneren ikke legger inn noe; forhåndsutfylte verdier ville vært synlige. Ingen skjermbilder tas bak innlogging (A.5). Bildene fra nettleserkontrollene maskerer inndatafelt (A.6).
Tekniske og organisatoriske tiltak	Punkt 8. Særlig: Bilder kan bare hentes via rapporten, og en annens bildeidentifikator gir «ikke funnet»; rapporter med noindex; hver kontroll kjører i sin egen isolerte container.

De samme opplysningene oppstår ved kontroller uten konto (gratis kontroll, studie, kontroll av potensielle kunder). Der finnes ingen Kunde vi handler på vegne av; disse tilfellene vises derfor i del B (B.5, B.7, B.8).

A.5 Testkontoens innloggingsopplysninger for skanning bak innlogging

Felt	Oppføring
Formål	Å lese skjemaer som først vises etter innlogging (kundeområde, medlemsområde). Skanneren logger inn med en testkonto som Kunden har opprettet på sitt eget nettsted, og leser de angitte sidene. Bortsett fra innloggingsskjemaet sender den ikke inn noe, utfører ingen aktiv test der, tar ingen skjermbilder og besøker ikke utloggings-, slette- eller avbestillingsadresser. Hvis innloggingsskjemaet har en CAPTCHA, stopper den; CAPTCHA-er omgås ikke.
Forutsetning	Verifisert domene, betalt abonnement, rolle som eier eller administrator, uttrykkelig bekreftelse på at kontoen er en testkonto. Høyst fem sider, alle på samme domene.
Kategorier av registrerte	Personen testkontoen står i navnet til (ideelt sett ingen; Kunden bør bruke en funksjonskonto); personer hvis opplysninger vises på sidene bak innloggingen.
Kategorier av personopplysninger	Brukernavn og passord til testkontoen, bare kryptert; et hint til brukernavnet (første tegn og lengde); innloggingsadresse, sideliste, navn på innloggingsfeltene, indikator for vellykket innlogging, personen som opprettet den, tidspunkter, siste resultat som en kort kode (domain_logins). For en pågående jobb en kopi av chifferteksten (feltet «innloggingspakke» i scan_jobs). Fra sidene bak innloggingen: skjemastruktur som i A.4, uten skjermbilder og uten informasjonskapsler.
Kilde	Oppgis av Kunden i kontoen.
Rettslig grunnlag (fastsatt av den behandlingsansvarlige)	Fastsettes av Kunden. Kunden innestår for å ha rett til å bruke testkontoen.
Mottakere	Ingen. Verken Kunden, kundestøtte eller programmeringsgrensesnittet kan lese ut innloggingsopplysningene; grensesnittet viser bare hintet til brukernavnet.
Tredjeland	Ingen.
Beskyttelse av innloggingsopplysningene	Brukernavn og passord krypteres umiddelbart ved lagring med skanneserverens offentlige nøkkel (X25519, HKDF-SHA256, AES-256-GCM; domenet bindes som tilknyttede data, slik at en chiffertekst ikke kan legges ved et annet domene). Bare skanneserveren har den private nøkkelen. Nettserver, database og sikkerhetskopier inneholder bare chiffertekst; heller ikke vi kan dekryptere den der. Skanneserveren dekrypterer bare for kjøringen, sender innloggingsopplysningene inn i den isolerte kontrollcontaineren bare via standard inndata, sletter kopien i jobben umiddelbart og skriver den ikke til noe resultat, noen logg eller feiltekst. På vei til Kundens nettsted beskyttes de bare av dette nettstedets kryptering; grensene for denne transporten er angitt i punkt 10.
Lagring	Lagrede innloggingsopplysninger frem til Kunden sletter dem. Ved sletting overskrives chifferteksten med tilfeldige data av samme lengde, og raden slettes; ventende jobber tømmes (fe_login_loeschen()). Med domenet forsvinner raden via en fremmednøkkel. Skanneserveren fjerner kopier i jobber etter kjøringen; alt som blir igjen (avbrutt jobb, skanneserver nede), fjernes av statuskjøringen senest etter én time (fe_login_aufraeumen(), delen «login_jobs»). Sikkerhetskopier av databasen inneholder chifferteksten frem til sikkerhetskopien utløper etter 14 dager.
Tekniske og organisatoriske tiltak	Punkt 8. Særlig: Asymmetrisk kryptering med atskilte nøkler; blokkeringsliste for utloggings- og slettestier; ingen skjermbilder bak innlogging; funksjonen bare for betalte abonnementer og verifiserte domener; hver endring i aktivitetsloggen (uten innloggingsopplysninger).

Vi har bevisst ikke bygget noen mulighet til å lagre innloggingsopplysninger til Kundens server, CMS-administrasjonsområde eller hostingkontoer. Testkontoen er en besøkskonto på Kundens nettsted, ikke tilgang til Kundens system.

A.6 Konfigurerte skjemaforløp, nettleserkontroller og uavhengig kontrollinstans

Felt	Oppføring
Formål	Et overvåket skjema gjennomgås i en reell nettleser (Chromium, WebKit eller begge) frem til punktet rett før innsending: laste siden, utføre forutgående klikk (høyst fem, aldri på et inndatafelt eller en sendeknapp), fylle felt med tydelig syntetiske verdier (som en adresse under den reserverte endelsen .invalid), gå videre i flertrinnsskjemaer. Nettleserkontrollen sender ikke inn noe; innsending er teknisk blokkert i nettleseren. I tillegg tidsmålinger og visuelle sammenligninger av skjemaet.
Kategorier av registrerte	Som A.4 (personer synlige på skjemasiden); Kundens ansatte som er oppgitt som ansvarlige (A.3).
Kategorier av personopplysninger	Konfigurasjon: skjemaadresse, selektorer, inngangsadresse, klikktrinn, nettleservalg, etikett, kritikalitet, tilordning, frist (monitored_forms). Resultater per kjøring: tilstand, teknisk feilårsak, rensede feilmeldinger, nettverks- og tidsmålinger, et bilde av skjemaet som JPEG på høyst 32 KB med maskerte inndatafelt (form_browser_runs). Observasjoner per kontroll (form_observations), tidsserier (form_performance). Jobber med en målliste (feltene «mål» og «resultat» i scan_jobs).
Testtilgang	Hvis Kunden har lagret en testkonto (A.5), bruker den fullstendige kontrollen den også for konfigurerte skjemaforløp. Ifølge den målte koden fungerer de frittstående nettleserkontrollene mellom to fullstendige kontroller uten testkonto.
Uavhengig kontrollinstans	Et andre kontrollpunkt på et annet sted er planlagt, som ville krysskontrollere før varsling. Det ville motta domenet, den rensede konfigurasjonen og jobbidentifikatoren, ingen inntastinger fra besøkende og ingen innloggingsopplysninger. Det er for tiden ikke satt opp (av som standard). Uten kontrollinstansen finnes ingen dokumentasjon fra et annet sted; et varsel bygger da på vår egen måling.
Kilde	Konfigurert av Kunden; resultater fra henting av Kundens side.
Rettslig grunnlag (fastsatt av den behandlingsansvarlige)	Fastsettes av Kunden for innholdet på Kundens nettsted og for ansvarsområdene til Kundens ansatte.
Mottakere	Kunden; der en kontrollinstans er satt opp, operatøren av denne (for tiden ingen).
Tredjeland	Ingen.
Lagring	Resultater fra nettleserkjøringer, fullførte nettleserjobber og tidsserier etter 13 måneder (nattlig slettekjøring, delene «browser_runs», «browser_jobs», «form_performance»). Konfigurasjoner frem til domenet slettes (enkeltvis kan de endres eller slås av, ikke slettes); med domenet forsvinner de sammen med kjøringer, observasjoner og tidsserier via fremmednøkler.
Hva målingen beviser	Tider og tilstander fra kontrollnettleseren vår. De måler ikke hva reelle besøkende opplever, og beviser verken fullføringsrater eller tapte henvendelser.
Tekniske og organisatoriske tiltak	Punkt 8. Særlig: Innsending teknisk forhindret; bare adresser på samme domene; maskerte bilder; isolert kontrollcontainer.

A.7 «Fix it for me» – innlimt skjemakode

Felt	Oppføring
Formål	Kunden limer inn koden til skjemaet sitt; en språkmodell på vår egen maskinvare bygger inn beskyttelsesmodulen. Det som returneres, er den endrede filen, en patch, resultatet av en syntakskontroll og en angivelse av om kontrollkallet faktisk er bygget inn. Uten innlimt kode leverer tjenesten en ferdig modul med feltnavnene fra den siste skanningen.
Kategorier av registrerte	Personer som tilfeldigvis har opplysninger i den innlimte koden (som en mottakeradresse, navn i kommentarer, innloggingsopplysninger til en e-postserver).
Kategorier av personopplysninger	Den innlimte koden, høyst 30 000 tegn. I databasen bare en oppføring i aktivitetsloggen (handlingen «fix_ai» med arbeidsområde og tidspunkt), som teller med i den daglige grensen på for tiden ti kall per arbeidsområde.
Kilde	Limt inn av Kunden.
Rettslig grunnlag	Oppfyllelse av avtalen med Kunden (personvernforordningen art. 6(1)(b)) for selve koden; for tredjepartsopplysninger som tilfeldigvis finnes i den, fastsetter Kunden grunnlaget.
Mottakere	Ingen. Språkmodellen kjører på vår egen skanneserver i det interne nettverket; ingen ekstern KI-tjeneste, heller ikke som reserve.
Tredjeland	Ingen.
Lagring	Koden lagres ikke. En midlertidig fil opprettes for syntakskontrollen og slettes umiddelbart etterpå. Oppføringen i aktivitetsloggen slettes etter 365 dager.
Merknad til Kunden	Kode som inneholder passord, API-nøkler eller personopplysninger, bør renses før den limes inn. Vi kontrollerer ikke innholdet.
Tekniske og organisatoriske tiltak	Punkt 8. Særlig: Bare eiere og administratorer med betalte abonnementer; den innlimte koden sendes til modellen merket som data og utføres aldri; ingen opplasting til tredjepartsservere.

A.8 Egen merkevare og byråets kontaktpersoner

Felt	Oppføring
Formål	Et byrås (Business-abonnement) rapporter, kortrapporter, dokumentasjonslogger og kundeportal vises under byråets merkevare, på forespørsel under byråets eget underdomene.
Kategorier av registrerte	Kontaktpersoner hos byrået som har navn eller kontaktopplysninger i kontaktlinjen.
Kategorier av personopplysninger	Firmanavn, nettsted, kontaktlinje, merknad til kunden, aksentfarge, utseende, logofil, bryter for henvisningen til formexposed, eget domene med verifikasjonsidentifikator og verifikasjonsstatus (workspace_branding).
Kilde	Oppgis av byrået.
Rettslig grunnlag	Oppfyllelse av avtalen med byrået (personvernforordningen art. 6(1)(b)). Der kontaktlinjen navngir byråets ansatte, fastsetter byrået grunnlaget.
Mottakere	Alle som byrået gir en rapport, kortrapport eller portallenke til.
Tredjeland	Ingen.
Lagring	Frem til byrået endrer opplysningene; merkevare og logofil forsvinner med arbeidsområdet (fe_arbeitsbereich_daten_loeschen()). Et eget domene der DNS-verifiseringen mislykkes i sju dager, slås av. Eget domene er av som standard.
Tekniske og organisatoriske tiltak	Punkt 8.

A.9 Tellinger, statusindikatorer og feltfeil fra tillegget og utvidelsen

Felt	Oppføring
Formål	Én gang om dagen rapporterer WordPress-tillegget og TYPO3-utvidelsen tall om skjemaene på det tilkoblede nettstedet: blokkerte innsendinger per årsak, innsendinger, sendte og mislykkede e-poster, statusindikatorer for skjemainnstillingene, lagrede henvendelser per kilde og lagringstid. Valgfritt, av som standard: skjemahendelser og feltfeilkategorier per feltposisjon. Disse tallene danner «Beskyttelse i tall», månedsrapporten, varsel om taushet og meldinger om risikable innstillinger.
Klassifisering	Tallene er utformet slik at de ikke beskriver noen person. Vi fører dem opp i del A fordi de oppstår fra hendelser på Kundens nettsted som utløses av Kundens besøkende; etter vårt syn er de personopplysninger høyst i grensetilfeller (et nettsted med svært få innsendinger en bestemt dag). Selve overføringen (nøkler, versjoner, vert) står i del B (B.20).
Kategorier av registrerte	Besøkende på Kundens nettsted som sender inn et skjema.
Kategorier av personopplysninger	Daglige tall per vert: blokkert totalt og per årsak, innsendinger, sendte og mislykkede e-poster, feilkategori ved e-postsending (bare én av fire kategorier, aldri feilteksten fordi den kan inneholde mottakeradresser), antall reCAPTCHA-svar, slettede og frigjorte henvendelser (plugin_stats). Status: versjoner fra en fast liste over skjema-, CAPTCHA- og e-posttillegg, innstillingsindikatorer som tall, lagringstider (plugin_health). Endringsmeldinger: navn og versjon på et oppdatert tillegg (plugin_changes). Valgfritt: tellere per skjema og dag med feilkategorier per feltposisjon (form_metrics). Aldri: inntastinger, feltnavn, passord, filer, e-postadresser, navn, IP-adresser eller vedvarende identifikatorer til besøkende.
Kilde	Tillegget på Kundens nettsted, via et programmeringsgrensesnitt med nettstedets tilkoblingshemmelighet.
Rettslig grunnlag (fastsatt av den behandlingsansvarlige)	Fastsettes av Kunden; Kunden bestemmer om de valgfrie tellingene skal aktiveres, og hvordan de besøkende skal informeres.
Mottakere	Kunden. Domener fra lenker i blokkerte meldinger går inn i svermbeskyttelsen (B.21).
Tredjeland	Ingen.
Lagring	Daglige tall, endringsmeldinger og skjematellere etter 13 måneder (nattlig slettekjøring, delene «plugin_stats» og «form_metrics»). Statusindikatorer overskrives ved hver rapport. Alle tilleggsopplysninger for en vert forsvinner så snart ingen domener i systemet lenger viser til verten (umiddelbart ved sletting av det siste domenet; eldre data nattlig, delen «orphan_hosts»).
Hva tallene beviser	Det tillegget telte. De beviser verken fullføringsrater eller tapte henvendelser.
Tekniske og organisatoriske tiltak	Punkt 8. Særlig: Mottak bare med nettstedets bundne nøkkelpar; bare kjente nøkler og tall godtas, alt annet forkastes; dager utenfor et vindu på 14 dager avvises.

A.10 Grensen: hva som bare blir på Kundens nettsted

Følgende funksjoner i WordPress-tillegget og TYPO3-utvidelsen behandler opplysninger utelukkende på Kundens server. De når ikke oss, og vi har ingen tilgang til dem. Nettstedoperatøren alene er ansvarlig; operatøren bestemmer aktivering, lagringstider og hvordan de besøkende informeres. Til dette foreslår tillegget avsnitt til operatørens personvernerklæring.

Funksjon	Hva som behandles lokalt	Lagring hos Kunden
Karantene	Stoppede innsendinger med årsak, kan frigjøres per e-post til nettstedets adresse	14 dager
Sikkerhetsnett	Innsendinger der skjema-e-posten mislyktes, for ny sending (på som standard)	30 dager
Regneoppgave i stedet for reCAPTCHA	Regneoppgave i den besøkendes nettleser, ingen tredjepartstjeneste (av som standard)	–
Lagringsinnstillinger	Sletting av lagrede henvendelser i skjematillegg etter perioden operatøren velger (av som standard)	som konfigurert
Begrensning av forespørselsfrekvens	en kortvarig identifikator avledet fra IP-adressen, overføres ikke til oss	kortvarig
Lokale dagstellere	Tellerverdier før overføring	høyst 14 dager
Opptaker for administratorer	tekniske selektorer og navigasjonstrinn i øktlageret i nettleseren til en innlogget administrator; inntastinger leses ikke. Bare den valgte konfigurasjonen overføres (deretter A.6)	høyst 15 minutter
Hjelp til besøkende	kan aktiveres separat; lagrer ingen utkast og sender ikke automatisk på nytt	–
Observasjon av nye spamregler	ytterligere treff telles lokalt, uten automatisk aktivering	sju dager

A.11 Skjemabeskyttelse (formconfirmed)

Felt	Oppføring
Formål	Vurdering av innsendinger via skjemaer på Kundens nettsteder for å gjenkjenne automatiserte innsendinger: utstedelse og kontroll av oppgaver (beregningsbevis), kontrolltokener til engangsbruk, utfyllingstid, fellefelt, gjentatte forespørsler; etter Kundens ønske vurdering av meldingsteksten ved hjelp av en språkmodell. Bare for Kunder som slår på skjemabeskyttelsen.
Kategorier av registrerte	Besøkende på Kundens nettsteder som åpner en side med et beskyttet skjema eller sender det inn.
Kategorier av personopplysninger	IP-adresse (lagres bare forkortet og hashet med en nøkkel som skiftes daglig), sidens adresse og domene, tidspunkter og utfyllingstid, fellefelt utfylt ja/nei, nettleseridentifikator i nettserverloggen; bare når innholdskontrollen er slått på, meldingsteksten (bare i arbeidsminnet).
Kilde	Den besøkendes nettleser (oppgave, kontrolltoken); Kundens server (kontrollforespørsel, eventuelt tekst).
Mottakere	Kunden (poengsum, handling, begrunnelser). Ingen andre; ingen underdatabehandlere for denne behandlingen.
Tredjeland	Ingen.
Lagring	Hashet identifikator 1 time; brukte kontrolltokener høyst 11 minutter; kontrollresultater uten IP-adresse og uten tekst 30 dager; dagstall 400 dager; nettserverlogg 14 dager; teksten lagres ikke.
Tekniske og organisatoriske tiltak	Punkt 8; i tillegg forkorting og hashing med dagsnøkkel, signerte oppgaver, engangsbruk, språkmodell på egen maskinvare uten logging av teksten.

4. Del A – mottakere, underdatabehandlere og tredjelandsoverføringer

Tabellen nedenfor oppgir mottakerne som vi selv engasjerer, og som kan motta opplysninger fra del A. Den avgjørende, løpende oppdaterte listen er siden Underdatabehandlere; hvis den avviker fra denne tabellen, er det et funn, ikke et formateringsproblem.

Mottaker	Hva mottakeren får	Tredjeland	Grunnlag	Status
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Kontrollpostkasse for leveringskontrollen (A.1); sending av varslings-e-poster (A.3), bekreftelser og rapporter til portalabonnenter (A.2)	Behandlingssted må fortsatt verifiseres; se siden «Underdatabehandlere»	Databehandleravtalen; overføringsgrunnlag må fortsatt verifiseres	Uavklart. Den relevante avtalen, de faktiske behandlingsstedene og overføringsgrunnlaget er ennå ikke dokumentert. Denne protokollen bekrefter verken en sertifisering eller en inngått avtale.
Namecheap, Inc. (registrar, DNS; videresending av e-post frem til postkassen er satt opp)	Frem til postkassen er satt opp, generell innkommende e-post til adresser på domenet vårt; ikke kopiene fra leveringskontrollen, som bare kommer frem med MX-oppføringer som peker direkte til postkassen (A.1)	USA	må verifiseres: sertifisering under EU-US Data Privacy Framework eller standard personvernbestemmelser	I bruk; grunnlaget uavklart.
Vår egen skanneserver med en lokal språkmodell	Skjemastruktur for klassifisering og utvalgte funn med skannemetadata for tiltaksplaner i betalte kontoer (A.4), innlimt kode (A.7), dekryptert testtilgang bare under kjøringen (A.5)	–	Drives av oss, ikke en tredjepart	I bruk.
Uavhengig kontrollinstans på et annet sted	Domene, renset konfigurasjon, jobbidentifikator (A.6)	avhengig av sted	må fastsettes før idriftsetting	Ikke satt opp.

Hosting: ingen tredjepart. Applikasjon, database, skjermbilder og sikkerhetskopier oppbevares på våre egne servere i Polen. Hvis vi flytter til et datasenter eller en skyleverandør, må dette avsnittet skrives om.

4.1 Varslingskanaler valgt av Kunden

I tillegg til mottakerne vi engasjerer, finnes kanaler som Kunden velger for varslene sine (A.3). Serveren vår utløser overføringen; Kunden bestemmer mottaker og leverandør. Å velge en kanal fritar oss ikke fra våre egne plikter som databehandler. Rolle, avtale og garantiene som kreves for tredjeland, må fastsettes for hver leverandør; for chattjenestene er dette ennå ikke fullført (åpent spørsmål for den juridiske gjennomgangen).

Kanal	Hva som sendes	Leverandørens forretningssted
E-post	Domene, hendelse, forklaring, lenke; til den oppgitte adressen	via Namecheap, Inc. (Private Email), Phoenix, Arizona, USA
Webhook til en fritt valgt adresse	Hendelse som JSON (domene, hendelser, linjer, lenke, tidsstempel), signert med mottakerens hemmelighet	bestemmes av Kunden
Slack, Discord, Microsoft Teams, Google Chat	samme varsling som en chatmelding til den oppgitte webhook-adressen	hovedsakelig USA
Telegram	mottaker valgt av Kunden; vi sender meldingen via boten vår til den tilkoblede chat-ID-en	utenfor EU, ingen beslutning om tilstrekkelig beskyttelsesnivå; overføringsgrunnlaget er et åpent spørsmål for den juridiske gjennomgangen

Innholdet i en melding fra en besøkende sendes aldri. Varslingene inneholder domene, hendelse og lenke.

5. Del B – art. 30(1): behandling under vårt eget ansvar

Behandlingsansvarlig for alt i denne delen: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, contact@lukaswojcik.com. Ingen representant kreves (etablert i Unionen). Intet personvernombud utpekt (punkt 9). Tekniske og organisatoriske tiltak: punkt 8 og siden Tekniske og organisatoriske tiltak. Hvordan registrerte utøver rettighetene sine, beskrives på siden Innsyn, sletting og dine øvrige rettigheter; kontoinnehavere kan selv laste ned opplysningene sine som en fil (Innstillinger).

Der vi bygger på berettigede interesser (personvernforordningen art. 6(1)(f)), oppgir vi interessen og grunnen til at et mindre inngripende middel ikke er tilstrekkelig. Avveiningen er vår vurdering; den er en del av den juridiske gjennomgangen.

B.1 Besøkende på nettstedet vårt – nettserverlogger

Felt	Oppføring
Formål	Drift og sikkerhet for nettstedet og applikasjonen: levering, feilsøking, oppdagelse av angrep og overbelastning.
Kategorier av registrerte	Alle som åpner en side på formexposed.com eller form.exposed, inkludert besøkende på Kundesider der nettleseren laster merkebildet vårt (B.18), mottakere som åpner en rapport- eller bekreftelseslenke, og nettsteder der tillegget kaller grensesnittet vårt.
Kategorier av personopplysninger	Fullstendig IP-adresse, tidspunkt, forespurt adresse, statuskode, overførte byte, henvisende side (referrer), nettleseridentifikator (user agent).
Lagringssted	Tilgangslogger fra den foranstilte proxyen og nettserveren som filer på nettserveren, ikke i databasen.
Kilde	Nettleseren eller programmet som sender forespørselen.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f). Interesse: Sikker og uavbrutt drift. Avveining: Uten den fullstendige adressen kan gjentatte forespørsler fra samme avsender ikke knyttes sammen og angrep ikke avverges; en avkortet adresse støtter ikke dette skillet. Loggene kombineres ikke med andre opplysninger og slettes etter kort tid.
Mottakere	Ingen.
Tredjeland	Ingen.
Lagring	14 dager: daglig rotasjon med 14 generasjoner, deretter overskriving (systemets loggrotasjonstjeneste, ikke applikasjonens nattlige slettekjøring).
Tekniske og organisatoriske tiltak	Punkt 8.

B.2 Applikasjonens sidevisningslogg

Felt	Oppføring
Formål	Sikkerhet og oppdagelse av misbruk (hvem forespør hva og hvor ofte), sporbarhet for kontotilgang, enkel bruksstatistikk uten analysetjeneste.
Kategorier av registrerte	Alle besøkende på nettstedet og brukere av applikasjonen ved faktiske sidevisninger (ingen bakgrunnsforespørsler, ingen skjemainnsendinger).
Kategorier av personopplysninger	Fullstendig IP-adresse, landet som utledes fra den ved skriving (lokal geodatabase, ingen forespørsel til tredjepart), konto-ID for innloggede brukere, forespurt adresse og henvisende side (tilgangstokener i dem, som i rapport- eller portallenker, maskert), nettleseridentifikator og enhetstype, operativsystem og nettleser utledet fra den, språk, tidspunkt (access_logs). Under «Vis som Kunde» (B.14) settes ingen konto-ID, slik at kundestøttens sidevisninger ikke vises i Kundens logg.
Kilde	Nettleserens forespørsel.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f). Interesse: Forebygging av misbruk og sporbarhet. Avveining: Som B.1; lagringstiden er lengre fordi misbruksmønstre blir synlige over uker. Om IP-adressen bør avkortes eller lagringstiden forkortes, er et åpent spørsmål for den juridiske gjennomgangen.
Mottakere	Ingen. Kontoinnehavere mottar sine egne sidevisninger i dataeksporten.
Tredjeland	Ingen.
Lagring	60 dager (nattlig mellom 03:00 og 03:05, srv/cron_status.php, innstillingen «sidevisningslogg»).
Tekniske og organisatoriske tiltak	Punkt 8. IP-adressen hentes fra et videresendt hode bare hvis forespørselen kommer fra vår egen foranstilte proxy, og da bare oppføringen denne proxyen har lagt til; ellers kunne alle oppgi opprinnelsen sin fritt.

B.3 Informasjonskapsler og lagring i nettleseren

Felt	Oppføring
Formål	Teknisk nødvendig lagring: økt, beskyttelse mot forfalskning av forespørsler på tvers av nettsteder (CSRF), telling av grensene for kontroller uten konto, innlogging, fortsatt innlogging på forespørsel, lys eller mørk visning.
Kategorier av registrerte	Besøkende og brukere av formexposed.com.
Kategorier av personopplysninger	Øktkapsel bpid (øktidentifikator; avsluttes når nettleseren lukkes; HttpOnly, SameSite=Lax, Secure over HTTPS). Informasjonskapsel bp_remember bare etter valg av «Hold meg innlogget» (selektor og verifikator; 30 dager). Lokal lagring bp_theme (lys, mørk eller system). I administrasjonsområdet i tillegg operatørenes lokale visningsinnstillinger. For grensene dannes en hash fra øktidentifikatoren; selve identifikatoren lagres ikke.
Settes ikke	Ingen analyse-, reklame- eller sporingsinformasjonskapsler. Partnerprogrammet (B.33) fungerer uten informasjonskapsel. Merkebildet på Kundesider setter ingen informasjonskapsel (B.18). reCAPTCHA kan sette informasjonskapsler fra Google når et beskyttet skjema sendes inn (B.23).
Rettslig grunnlag	Tilgang til terminalutstyret: strengt nødvendig for tjenesten brukeren ber om (§ 25(2) nr. 2 TDDDG, den tyske loven om personvern for digitale telekommunikasjonstjenester; art. 399(3) PKE, den polske loven om elektronisk kommunikasjon (Prawo komunikacji elektronicznej)). Behandling: personvernforordningen art. 6(1)(b) (konto) og (f) (sikkerhet, grenser).
Mottakere	Ingen.
Tredjeland	Ingen.
Lagring	Økt; 30 dager for husk-meg-tokenen. Den nattlige kjøringen sletter utløpte husk-meg-tokener i databasen (remember_tokens); ved utlogging, passordendring og tilbakekalling av en enhet umiddelbart.
Tekniske og organisatoriske tiltak	Punkt 8.

B.4 Gratis kontroll uten konto – mottak, grenser og overvåking av misbruk

Felt	Oppføring
Formål	Alle kan få et domene kontrollert uten konto. For at inndatafeltet ikke skal bli et våpen mot tredjepartsnettsteder, gjelder trinnvise grenser: én anonym kontroll per domene på sju dager (deretter samme rapport), grenser per IP-adresse og per økt på 24 timer, en dagsgrense for hele systemet, blokkering av svært unge domener, blokkeringsliste og opt-out, bare offentlige adresser. Påfallende mønstre registreres og rapporteres til operatøren. Grensene per IP-adresse, per økt og for hele systemet, hver telt separat, gjelder også kontroll fra tillegget uten konto (et tillegg med et bundet nøkkelpar telles per nettsted i stedet for per adresse) og opt-out (B.30); det gratis verktøyet for HTTP-hoder (B.9) har egne grenser per IP-adresse og dag og for hele systemet.
Kategorier av registrerte	Personer som utløser en kontroll, en forespørsel til verktøyet for HTTP-hoder eller et opt-out; servere der et tillegg er installert.
Kategorier av personopplysninger	Logg over hver forespørsel: kilde (kontroll, tillegg, verktøy for HTTP-hoder, opt-out), fullstendig IP-adresse, hash av øktidentifikatoren, kontrollert vert, land fra IP-adressen, godtatt eller avvist med årsak, tidspunkt (check_throttle). Avvik: type (IP-adresse, økt, land, system), nøkkel (for typen «IP» den fullstendige IP-adressen), mønster, alvorlighetsgrad, kort beskrivelse, tidspunkter for oppdagelse og løsning, personen som løser det (abuse_flags). Jobb: vert, modus, tillitsnivå og en avkortet økthash som identifikator for den som ber om kontrollen (scan_jobs). Rapport: tilfeldig identifikator, vert, språk, utløp, første visning, antall visninger (reports). Mellomlagret domenealder fra registeroppslaget (domain_age_cache).
Kilde	Personens inndata; forespørselen; registeroppslag (RDAP) for domenealderen.
Rettslig grunnlag	Utførelse av den bestilte kontrollen: personvernforordningen art. 6(1)(b) (bruk av den gratis kontrollen etter Bruksvilkårene); subsidiært (f). Grenser og overvåking: art. 6(1)(f). Interesse: Å forhindre at tjenesten brukes som et verktøy mot tredjepartsnettsteder eller som en spamkanon. Avveining: Uten kobling til adressen og økten kunne grensene ikke håndheves; perioden på sju dager er like kort som den lengste grensen som telles ut fra den.
Mottakere	Google (reCAPTCHA ved innsending, B.23). For domenealderen forespør skanneren RDAP-omdirigeringstjenesten rdap.org, som videresender til det ansvarlige registeret; bare domenenavnet overføres. Når et avvik oppstår, mottar operatøren et signal via Telegram uten noen variabel (ingen vert, ingen adresse). Rapporten kan sees av alle som har den tilfeldige lenken.
Tredjeland	USA via reCAPTCHA (B.23).
Lagring	Forespørselslogg 7 dager (nattlig, srv/cron_status.php). Løste avvik 90 dager etter løsning; uløste beholdes frem til noen løser dem (punkt 10). Anonyme rapporter utløper etter 30 dager; den nattlige kjøringen sletter deretter rapport, jobb, kontrollresultat, skjemaer, funn og bilder (fe_reports_aufraeumen()). En administrator kan manuelt frigi oppføringer for en adresse; dette sletter loggen for adressen for de siste 24 timene.
Tekniske og organisatoriske tiltak	Punkt 8. Nødstopp for alle anonyme kontroller i administrasjonsområdet; kapasitetsstyring som ikke tar imot nye gratis kontroller når det finnes et etterslep.

B.5 Crawlerkontroll av tredjepartsnettsteder

Felt	Oppføring
Formål	Sikkerhetskontroll av offentlige kontaktskjemaer: beskyttelse mot spam og misbruk, personvern- og tilgjengelighetsegenskaper, innebygde tredjepartsskript, atferd etter avvisning i informasjonskapselbanneret, mobilvisning. Gjelder kontroller uten konto (B.4), domener i en konto som ennå ikke er verifisert, og som grunnlag for studien (B.7) og kontrollen av potensielle kunder (B.8). For verifiserte domener i en konto handler vi på Kundens vegne (A.4).
Crawlerens atferd	Egen identifikator med henvisning til crawler-siden; leser robots.txt før kontrollen og stopper hvis en disallow-regel omfatter startsiden (også hvis robots.txt ikke er tilgjengelig eller det er en serverfeil); disallow-regler for enkelte understier følges ikke separat. Skjemapuls, henting av dokumentasjon på kontroll, verktøyet for HTTP-hoder og søket etter tilgjengelige filer leser ikke robots.txt. Høyst åtte offentlige sider per kontroll, pluss inntil tre sider med et klikk på «Avvis» i informasjonskapselbanneret, inntil tre sider i mobilvisning, aktive prøver for verifiserte domener og inntil fem sider bak innlogging (A.5); sidene lastes etter hverandre, ikke parallelt; bare offentlige adresser, ingen interne nettverk, omdirigeringer kontrolleres på nytt; blokkeringsliste og opt-out kontrolleres før mottak og en gang til i skanneren. Passivt: Uten dokumentasjon på kontroll sendes ingenting inn for Kunder (unntak: interne kontroller av våre egne test- og demonstrasjonsdomener, B.6).
Kategorier av registrerte	Operatører av de kontrollerte nettstedene (der de er fysiske personer, som enkeltpersonforetak); personer som tilfeldigvis er synlige på de kontrollerte sidene.
Kategorier av personopplysninger	Som A.4: sideadresser og titler, skjemastruktur (feltnavn, typer og etiketter, ingen feltverdier), beskyttelsestiltak, tredjepartsskript (adresser; konto-ID-er for piksler og opptaksverktøy erstattes før lagring), atferd ved informasjonskapselbanner, skjermbilder (synlig område på startsiden, skjemaer). Hvis en mottakeradresse vises i skjemaet, bare domenet (scans, forms, findings, scan_screenshots).
Kilde	Offentlig tilgjengelige sider.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f). Interesse: Å utføre den bestilte sikkerhetskontrollen; gjøre nettstedoperatører oppmerksomme på svakheter som kan skade de besøkende. Avveining: Bare det enhver besøkende ser, leses, i lite omfang og uten innsending; operatøren kan når som helst permanent unnta domenet uten dokumentasjon. Informasjon etter personvernforordningen art. 14 gis via crawler-siden, opt-out og Personvernerklæringen; om dette er tilstrekkelig etter art. 14(5)(b), er et åpent spørsmål for den juridiske gjennomgangen.
Mottakere	Den som utløser rapporten, og alle som vedkommende gir den tilfeldige lenken til; den lokale språkmodellen på vår egen server der skjematypen er uklar (skjemastruktur, sidetittel og adresse, skjemaets synlige tekst). Sårbarhetsvarsler fra tilleggsversjoner vises aldri i anonyme rapporter.
Tredjeland	Ingen.
Lagring	Anonymt: 30 dager (B.4). Kontroll av potensielle kunder: 90 dager (B.8). Studie: frem til publisering (B.7). Domene i en konto: høyst 13 måneder, den siste kontrollen beholdes; umiddelbart med domenet. Interne kontroller fra operatøren uten domene og uten rapport (som dem som opprettes fra kommandolinjen): ingen lagringstid (punkt 10). Midlertidige filer på skanneserveren slettes etter hver kjøring.
Tekniske og organisatoriske tiltak	Punkt 8. Særlig: Separat kontrollcontainer med reduserte rettigheter, skrivebeskyttet filsystem, minnegrense og eget nettverk; dobbel målkontroll.

B.6 Aktive testinnsendinger

Felt	Oppføring
Formål	Å kontrollere om et kontaktskjema godtar en innsending uten beskyttelse, om CAPTCHA, felle (honeypot), token, validering av e-postadresse og begrensning av forespørselsfrekvens virker på serversiden, og om hoder kan injiseres.
Forutsetning	For Kunder bare for domener der dokumentasjon på kontroll er gitt (DNS-oppføring, metatagg, fil eller tilkoblet tillegg); i tillegg bruker operatøren et internt kommandolinjeverktøy til å opprette kontroller med nivået «verified» for våre egne test- og demonstrasjonsdomener. Bare med den globale bryteren på, bare for et skjema som med sikkerhet er klassifisert som et generelt kontaktskjema. Aldri for bestillinger, bookinger, registreringer, nyhetsbrev, betalinger, filopplastinger, obligatoriske felt med reelle personopplysninger eller domener til offentlige myndigheter, helse- eller utdanningsinstitusjoner.
Kategorier av registrerte	Kundens ansatte som mottar skjema-e-postene.
Kategorier av personopplysninger	Testinnsendingen inneholder ingen personopplysninger: avsender «FormExposed Security Scanner», vår egen avsenderadresse eller en adresse under .invalid, en merket emnelinje og en tekst på sidens språk med henvisning til crawler-siden og opt-out og kontrollnummeret. Lagret hos oss: sidens svar, funn, et bilde av oppfølgingssiden (som A.4).
Omfang	Høyst fem innsendinger per kontroll (innstilling, standard 5); gjentas med abonnementets kontrollhyppighet, daglig i det høyeste abonnementet.
Kilde	Kundens instruks.
Rettslig grunnlag	Oppfyllelse av avtalen med Kunden (personvernforordningen art. 6(1)(b)); innsendingene går til Kundens eget skjema. For mottakerne hos Kunden: Kundens organisering.
Mottakere	Kunden (Kundens skjema-e-post).
Tredjeland	Ingen gjennom oss.
Lagring	Resultater som A.4.
Tekniske og organisatoriske tiltak	Punkt 8. Hodeinjeksjon oppdages bare, utføres aldri med en reell mottaker; valideringen av e-postadressen bruker bare et domene som ikke kan eksistere.

B.7 Studien «Skjemasikkerhetsindeks»

Felt	Oppføring
Formål	Statistikk om beskyttelsen av kontaktskjemaer i et land eller en sektor. Bare samlede tall publiseres, uten navn på nettsteder; segmenter bare fra 20 sider med et skjema.
Kategorier av registrerte	Operatører av nettstedene på listen; personer som tilfeldigvis er synlige.
Kategorier av personopplysninger	Som B.5, bare passivt. I tillegg listen: vert, segment, status, jobb (study_domains); studie med tittel, land, samlede resultater (studies).
Kilde	En liste over offentlige nettsteder satt sammen av operatøren; selve sidene.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f). Interesse: Statistiske utsagn om skjemasikkerhetens tilstand. Avveining: Passivt, begrenset frekvens (få jobber per kjøring), blokkeringsliste og opt-out gjelder, publisering bare som samlede tall, rådata slettes.
Mottakere	Offentligheten, bare samlede tall.
Tredjeland	Ingen.
Lagring	Rådata (kontrollresultater, skjemaer, funn, bilder, jobber) slettes ved publisering (fe_studie_veroeffentlichen()). Listen over verter med segment beholdes etterpå; det finnes ingen lagringstid for den eller for studier som aldri publiseres (punkt 10). Operatøren bestemmer hvilke lister som kontrolleres, og om studier publiseres.
Tekniske og organisatoriske tiltak	Punkt 8.

B.8 Kontroll av potensielle kunder (kundevervingsmodus for byråer)

Felt	Oppføring
Formål	Et byrå (Business-abonnement) kontrollerer passivt nettstedet til en potensiell kunde og mottar en kortrapport under egen merkevare og den passive rapporten. Vi kontakter ingen; byrået videreformidler lenken selv.
Kategorier av registrerte	Operatøren av det kontrollerte nettstedet; personer som tilfeldigvis er synlige; byråets ansatte som utløser kontrollen.
Kategorier av personopplysninger	Som B.5, bare passivt. I tillegg: arbeidsområde, personen som utløser kontrollen, vert, tilfeldig rapportidentifikator, tidspunkt (prospect_checks).
Kilde	Byråets inndata; offentlige sider.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f) (vår interesse i å levere tjenesten og byråets interesse i en velbegrunnet henvendelse). Rollene til byrået og oss og byråets plikter ved videreformidling av rapporten er åpne spørsmål for den juridiske gjennomgangen: Hvis byrået sender rapporten uanmodet per e-post eller ringer, er dette direkte markedsføring som krever samtykke etter art. 398 PKE og § 7(2) UWG (den tyske loven mot illojal konkurranse), også mellom næringsdrivende. Dette er byråets ansvar; Bruksvilkårene forplikter byrået tilsvarende.
Mottakere	Byrået og alle som får lenken av byrået.
Tredjeland	Ingen.
Lagring	Rapport og kontrollresultat utløper etter 90 dager og slettes deretter av den nattlige kjøringen (fe_reports_aufraeumen()); kontrolloppføringen slettes etter 90 dager i den daglige svermkjøringen fra 04:00 (srv/cron_status.php). Med arbeidsområdet umiddelbart.
Tekniske og organisatoriske tiltak	Punkt 8. Månedlig kvote (innstilling, standard 30); samme side innen sju dager gir samme rapport; opt-out gjelder.

B.9 Verktøy for HTTP-hoder uten konto

Felt	Oppføring
Formål	Gratis karakter (A+ til F) for sikkerhetshodene til startsiden på et domene. To forespørsler, ingen nettleser, intet skjema, ingen innsending.
Kategorier av registrerte	Personer som bruker verktøyet; operatører av det kontrollerte domenet.
Kategorier av personopplysninger	Forespørselslogg som B.4 (kilden «headers», IP-adresse, økthash, vert). Resultat: vert, karakter, poeng, vurderte hoder (header_checks).
Rettslig grunnlag	Personvernforordningen art. 6(1)(f), som B.4 og B.5.
Mottakere	Google (reCAPTCHA, B.23).
Tredjeland	USA via reCAPTCHA.
Lagring	Forespørselslogg 7 dager; resultater etter for tiden 90 dager (nattlig slettekjøring, delen «header_checks», innstillingen «headers_keep_days»). For domener i en konto fastsettes karakteren på nytt daglig og lagres med domenet.
Tekniske og organisatoriske tiltak	Punkt 8. Grenser per IP-adresse og dag; opt-out gjelder.

B.10 Kundekontoer

Felt	Oppføring
Formål	Drift av kundekontoer, arbeidsområder og abonnementer.
Kategorier av registrerte	Kunder (næringsdrivende) og teammedlemmene deres med egen konto.
Kategorier av personopplysninger	E-postadresse og normalisert form, passord bare som en hash, fornavn (obligatorisk), etternavn og firma (der oppgitt); applikasjonen lagrer ikke adresse og merverdiavgiftsnummer, de oppgis bare hos Stripe (B.26); status, språk, visningsmodus, valuta, abonnement og faktureringsstatus, Stripe-kunde- og abonnements-ID, slutten av faktureringsperioden, oppsigelse ved periodens slutt, bekreftelses- og tilbakestillingsidentifikatorer med utløp, ny e-postadresse frem til bekreftelse, registreringstidspunkt, siste innlogging og siste IP-adresse, tidspunkt da alle økter ble tilbakekalt, tofaktoropplysninger (B.11), månedsrapport på/av, tidspunkt for påminnelses-e-posten, opplåsinger via koder, henvisningskode og henvisning (users). Arbeidsområder med navn, tidspunkter, status (workspaces); medlemskap med rolle og innmeldingsdato (workspace_users).
Kilde	Personens registrering og innstillinger; faktureringsstatus fra Stripe.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) (avtale). Siste IP-adresse: (f) (kontosikkerhet).
Mottakere	Stripe (B.26); e-postleverandør for konto-e-poster (B.25). Medlemmer av samme arbeidsområde ser navn, e-postadresse og rolle for de andre medlemmene.
Tredjeland	Via Stripe og e-postleverandøren.
Lagring	Frem til kontoinnehaveren sletter kontoen. Ved sletting forsvinner innehaverens egne arbeidsområder som ingen andre bruker, med alle domener og tilhørende opplysninger; arbeidsområder med flere medlemmer overføres til et annet medlem, først til administratorer og blant dem til den som har vært medlem lengst. Medlemskap, husk-meg-tokener, enheter, API-nøkler, åpne Telegram-koder, tilbakemeldinger på rapporter (B.35) og kontoraden slettes; et løpende betalt abonnement avsluttes først umiddelbart hos Stripe uten refusjon (www/ajax.php, fe_konto_reste_loeschen()). En oppsigelse i faktureringsområdet får derimot virkning ved periodens slutt; deretter fortsetter kontoen med gratisabonnementet. Hva som beholdes, fremgår av punkt 6.4. Kontoer som aldri er bekreftet og aldri har vært logget inn på, slettes etter 30 dager, med mindre et annet medlem er knyttet til arbeidsområdet (nattlig slettekjøring, delen «pending_accounts»). Inaktive kontoer slettes ikke. Hvis avtalen om kontoen opphører på en annen måte, for eksempel ved vår oppsigelse, sletter vi kontoen senest 30 dager etter avtalens opphør; dette gjøres for tiden manuelt (forpliktelse i Databehandleravtalen).
Tekniske og organisatoriske tiltak	Punkt 8.

B.11 Innlogging, enheter, andre faktor og aktivitetslogg

Felt	Oppføring
Formål	Beskyttelse av kontoer: begrensning av innloggingsforsøk og andre passordforsøk, visning og tilbakekalling av innloggede enheter, tofaktorinnlogging, sporbarhet for endringer.
Kategorier av registrerte	Kontoinnehavere og teammedlemmer; personer som forsøker en innlogging, en registrering eller passordet til en kundeportal.
Kategorier av personopplysninger	Innloggingsforsøk: IP-adresse, angitt e-postadresse, om forsøket lyktes, tidspunkt (login_attempts). Enheter: hash av øktidentifikatoren (aldri selve identifikatoren), kobling til husk-meg-tokenen, IP-adresse, nettleseridentifikator og nettleser, operativsystem og enhetstype utledet fra den, tidspunkter for innlogging, siste aktivitet og tilbakekalling, og for «Vis som Kunde» identifikatoren til kundestøttepersonen (login_sessions). Husk-meg-tokener for «Hold meg innlogget»: selektor, verifikator, utløp (remember_tokens). Tofaktor: hemmelighet kryptert, aktiveringstidspunkt, siste brukte tidstrinn, gjenopprettingskoder bare som en hash (i users). Aktivitetslogg: konto, arbeidsområde, handling, mål, detaljer, IP-adresse, land, tidspunkt (audit_logs). Forsøkstellere for innlogging, andre faktor, passordbekreftelse, tilbakestilling av passord, registrering og passord til kundeportaler: en HMAC-nøkkel avledet fra formålet og konto-ID-en (for en ukjent adresse eller tilbakestilling e-postadressen med små bokstaver), IP-adressen, konto og IP-adresse sammen eller portal-ID-en (også sammen med IP-adressen), antall forsøk, utløp; e-post- og IP-adresser lagres ikke der i klartekst (tabell auth_attempt_buckets).
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) sammenholdt med art. 32 (enhetsliste, andre faktor) og (f) (innloggingsforsøk, aktivitetslogg). Interesse: Å beskytte kontoer mot overtakelse, dokumentere endringer (art. 5(2)). Avveining: En avkortet adresse besvarer ikke spørsmålet «var det meg?»; aktivitetsloggen må vare lenger enn en tvist som først oppstår måneder senere.
Mottakere	Ingen. Kontoinnehaveren ser enhetene sine og mottar innloggingsforsøk, enheter og aktiviteter i dataeksporten; under en «Vis som Kunde»-økt vises verken IP-adressen eller nettleseren til kundestøttepersonen der.
Tredjeland	Ingen.
Lagring	Innloggingsforsøk 7 dager; etter en vellykket innlogging slettes mislykkede forsøk fra samme adresse umiddelbart. Forsøkstellere ved slutten av tidsvinduet (for tiden 15 minutter, én time for tilbakestilling av passord og registrering); utløpte slettes ved neste tilgang og av den nattlige kjøringen. Enheter 90 dager etter siste bruk eller etter tilbakekalling (nattlig slettekjøring, delen «sessions»), umiddelbart med kontoen. Husk-meg-tokener utløper etter 30 dager. Aktivitetslogg 365 dager (nattlig); når en konto slettes, beholdes oppføringene frem til slutten av lagringstiden (punkt 6.4).
Tekniske og organisatoriske tiltak	Punkt 8.

B.12 Dokumentasjon på avtaleinngåelse

Felt	Oppføring
Formål	Å dokumentere hvilken versjon av Bruksvilkårene, Databehandleravtalen og Personvernerklæringen en Kunde godtok eller tok til etterretning ved registrering, og at Kunden bruker tjenesten for næringsvirksomheten sin.
Kategorier av registrerte	Kunder.
Kategorier av personopplysninger	Per dokument: konto, dokument, versjon (hash av den viste teksten), anledning, IP-adresse, nettleseridentifikator, tidspunkt (legal_consents). Selve den viste versjonen med full tekst, språk, tittel og adresse, én gang per versjon (legal_versions; inneholder ingen personopplysninger).
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) og (f) (dokumentasjon på avtaleinngåelse, forsvar mot krav).
Mottakere	Ingen. Kontoinnehaveren mottar registreringene sine i dataeksporten.
Tredjeland	Ingen.
Lagring	Så lenge kontoen finnes; etter at kontoen er slettet, fire år fra samtykket, deretter sletting nattlig (srv/cron_status.php). Begrunnelse i koden: tre års foreldelsesfrist fra årets slutt, avrundet opp. Om polsk rett tilsier en annen periode, er en del av den juridiske gjennomgangen.
Tekniske og organisatoriske tiltak	Punkt 8. Hvis ett av de tre dokumentene mangler, er registreringen stengt.

B.13 Teaminvitasjoner

Felt	Oppføring
Formål	Å invitere flere personer til et arbeidsområde.
Kategorier av registrerte	Inviterte personer.
Kategorier av personopplysninger	E-postadresse, rolle, invitasjonsidentifikator, inviterende person, utløp, tidspunkt for aksept (workspace_invites); invitasjons-e-posten i utboksen (B.25).
Kilde	Oppgis av medlemmet som inviterer.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) i forhold til Kunden; overfor den inviterte personen (f) (Kundens interesse i å involvere teamet sitt).
Mottakere	E-postleverandør (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Tredjeland	Via e-postleverandøren.
Lagring	En invitasjon er gyldig i 14 dager og bare så lenge den inviterende personen er eier eller administrator av arbeidsområdet. Ikke godtatte invitasjoner etter utløp, godtatte 30 dager etter aksept (nattlig, srv/cron_status.php og delen «invites» i cfg/fristen_lib.php). Med arbeidsområdet umiddelbart.
Tekniske og organisatoriske tiltak	Punkt 8.

B.14 «Vis som Kunde» fra kundestøtte

Felt	Oppføring
Formål	En superadministrator ser applikasjonen slik en Kunde ser den, for å løse et spørsmål til kundestøtte («jeg mangler knappen»).
Kategorier av registrerte	Den berørte Kunden; superadministratoren.
Kategorier av personopplysninger	Alt Kunden ser i applikasjonen. Loggført: en separat enhetsrad med superadministratorens identifikator (login_sessions), start og slutt i aktivitetsloggen (audit_logs).
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) (kundestøtte som del av tjenesten), alternativt (f).
Grenser	Høyst én time, deretter fullstendig utlogging. Avslutning av visningen logger også superadministratoren helt ut, inkludert økten vedkommende kom fra; retur til administrasjonsområdet krever ny innlogging med passord og andre faktor. Avsluttes umiddelbart hvis superadministratoren nedgraderes eller sperres. Alt som endrer Kundens konto, er blokkert: passord, e-postadresse, andre faktor, enheter, abonnement, eksport, sletting, overføring. Administrasjonsområdet er stengt under økten. Kunden ser tilgangen i enhetslisten og dataeksporten som kundestøttetilgang.
Mottakere	Ingen.
Tredjeland	Ingen.
Lagring	Enhetsrad 90 dager, aktivitetslogg 365 dager.
Tekniske og organisatoriske tiltak	Punkt 8.

B.15 Domener, dokumentasjon på kontroll og overvåking

Felt	Oppføring
Formål	Kjernetjenesten for Kunder: ha domener i kontoen, fremlegge dokumentasjon på kontroll, kontrollere regelmessig og oppdage endringer. Dette omfatter skjemapulsen (en lett forespørsel uten nettleser hvert 10. til 30. minutt avhengig av abonnementet), daglig overvåking av e-post-DNS og sertifikater, domenets utløpsdato, blokkeringslister, tilgjengelige filer, versjoner synlige utenfra, skriptoversikt, visuelle endringer i skjemaet, driftsavbrudd hos CAPTCHA- og e-postleverandører og overvåking av sårbarheter i skjematillegg.
Kategorier av registrerte	Kunder og teammedlemmene deres; domenenes operatører der de er fysiske personer.
Kategorier av personopplysninger	Domene med vert, offentlig identifikator, merknad, kundeetikett, type og identifikator for dokumentasjonen, kontrollhyppighet, overvåking på/av, vedlikeholdsvinduer, verdi per henvendelse, identifikatorer for merke, leveringskontroll og utrullingshook, tilleggsnøkkel, tilstander og siste resultater fra overvåkingen (DNS, sertifikat, autentisiteten til skjema-e-posten, blokkeringslister, tilgjengelige filer, hoder, versjoner) (domains). Puls per skjemaside (form_pulse). Sårbarheter fra tilleggsversjoner (vuln_hits). Skriptoversikt med adresse, hash, størrelse, godkjenning med godkjennende person og begrunnelse (script_inventory, script_changes). Kontroller som A.4. For tilgjengelige filer lagres sti, alvorlighetsgrad og type, aldri innholdet.
Forespørsler til tredjeparter	DNS-forespørsler (SPF, DMARC, MX, dokumentasjonsoppføring). Registeroppslag via RDAP etter IANA-katalogen: bare domenenavnet. DNS-blokkeringslister (SpamCop, PSBL, Mailspike, SURBL; Spamhaus bare med lagrede tilgangsopplysninger, for tiden ikke): IP-adressene til nett- og e-postserveren og domenenavnet, ingen besøksopplysninger. Google Web Risk bare hvis satt opp (for tiden ikke): startsidens adresse. Tidsstemplingstjeneste: bare en hashverdi (B.19). WPVulnerability: bare identifikatoren til et tillegg eller tema, eller WordPress-versjonen; vi utfører selv sammenligningen med den installerte tilleggsversjonen. Statussider for Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun og Brevo: ingenting overføres ut over selve forespørselen.
Kilde	Kunden; forespørsler til Kundens side; offentlige kataloger.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b).
Mottakere	De nevnte tjenestene mottar ingen personopplysninger om Kundene våre i den utstrekning et foretaks domenenavn og serveradresser ikke er personopplysninger; for enkeltpersonforetak kan domenenavnet være en personopplysning. Arbeidsområdets medlemmer ser domenet.
Tredjeland	Forespørslene kan nå tjenester i tredjeland (som registeroppslag, blokkeringslister). Bare det som oppgis i raden «Forespørsler til tredjeparter», overføres.
Lagring	Frem til domenet slettes. fe_domain_loeschen() sletter da umiddelbart kontrollresultater, skjemaer, funn, bilder, rapporter, jobber, varslingsmottakere og varslingslogg, hendelser, Telegram-koder, leveringer, puls, sårbarheter og dokumentasjon; via fremmednøkler overvåkede skjemaer, nettleserkjøringer, testkonto og skjematellere; vertens tilleggsopplysninger hvis intet annet domene viser til den. Også domenets skriptoversikt og skriptendringer slettes; de har ingen egen lagringstid (punkt 6.4). Kontrollresultater høyst 13 måneder, det siste beholdes.
Tekniske og organisatoriske tiltak	Punkt 8. Overvåking av tilgjengelige filer og versjoner bare for verifiserte domener, høyst én forespørsel per sti, bare de første 8 KB; uanmodet prøving av tredjepartsstier ville vært et angrepsverktøy.

B.16 Varsler, hendelser og eskalering overfor kontoinnehaveren

Felt	Oppføring
Formål	Å informere Kunden om feil og endringer, overholde vedlikeholdsvinduer, bekrefte og eskalere hendelser. Der mottakerne er tredjeparter, handler vi på Kundens vegne (A.3); der det er kontoinnehaveren selv, er det angitt her.
Kategorier av registrerte	Kontoinnehavere og teammedlemmer som mottakere.
Kategorier av personopplysninger	Som A.3. Varslinger vises på kontoinnehaverens språk.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b).
Mottakere	E-postleverandør; valgte chattjenester (4.1).
Tredjeland	Avhengig av kanalen (4.1).
Lagring	Som A.3: leveringslogg 90 dager, sammendragsvarslinger 30 dager etter levering, hendelser frem til løsning og deretter 180 dager. Varslingsmottakere med domenet.
Tekniske og organisatoriske tiltak	Punkt 8.

B.17 Månedsrapport til kontoer

Felt	Oppføring
Formål	Den 1. i hver måned fra 08:00 (etterkjøring frem til den 3.) én e-post per konto som omfatter alle domenene: nivå, poengsum og endring, varsler, blokkerte boter, e-postsending, sammenligningsverdi.
Kategorier av registrerte	Aktive kontoinnehavere med månedsrapporten slått på.
Kategorier av personopplysninger	E-postadresse, språk, nøkkeltall for domenene.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) (en del av tjenesten). Kan meldes av i innstillingene; kan slås av sentralt.
Mottakere	E-postleverandør (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Tredjeland	Via e-postleverandøren.
Lagring	Ingen separat lagring; e-posten forblir i utboksen i 30 dager (B.25).
Tekniske og organisatoriske tiltak	Punkt 8.

B.18 Merke og offentlig bekreftelsesside

Felt	Oppføring
Formål	En Kunde kan bygge inn et merkebilde på nettstedet sitt og lenke det til en offentlig bekreftelsesside. Merket viser «Beskyttet» bare hvis domenet er verifisert, overvåkingen kjører og den siste fullførte kontrollen er høyst 45 dager gammel og ga resultatet «Beskyttet» eller «Delvis beskyttet»; ellers viser det nøytralt «Kontroll av kontaktskjema». Bekreftelsessiden oppgir nivå og dato, ingen enkeltfunn.
Kategorier av registrerte	Besøkende på Kundens nettsted der nettleseren laster bildet; besøkende på bekreftelsessiden.
Kategorier av personopplysninger	Når bildet lastes: IP-adresse, tidspunkt, forespurt adresse, henvisende side og nettleseridentifikator i nettserverloggen (B.1). Bildeadressen starter ingen økt, setter ingen informasjonskapsel og skriver ikke til sidevisningsloggen. Bekreftelsessiden er en vanlig side (B.2, B.3).
Rettslig grunnlag	Personvernforordningen art. 6(1)(f). Interesse: Å levere bildet og holde driften sikker. Om Kunden og vi er felles behandlingsansvarlige for overføringen av den besøkendes IP-adresse i henhold til rettspraksis om innebygd tredjepartsinnhold, og om en ordning etter art. 26 kreves, er et åpent spørsmål for den juridiske gjennomgangen. Kunden mottar tekstforslag til personvernerklæringen.
Mottakere	Ingen.
Tredjeland	Ingen.
Lagring	14 dager (nettserverlogg). Bildet mellomlagres i én time. Når merket slås av, opphører identifikatorens gyldighet.
Tekniske og organisatoriske tiltak	Punkt 8.

B.19 Dokumentasjonslogg og tidsstempel

Felt	Oppføring
Formål	Én logg per domene og måned (betalte abonnementer): hva som ble kontrollert, med hvilket resultat, hva som ble rapportert og hva som endret seg, som dokumentasjon for ansvarlighet, forsikringsselskaper eller leverandørrevisjoner. Hver versjon får et kontrollnummer; en offentlig side bekrefter domene, periode og nøkkeltall, ingen detaljer. Siden 7. oktober 2026 har en tidsstemplingstjeneste etter RFC 3161 bekreftet tidspunktet.
Kategorier av registrerte	Kunder; indirekte personer som kan navngis i loggen som godkjennende eller bekreftende personer.
Kategorier av personopplysninger	Domene, måned, kontrollnummer, innholdshash (SHA-512), sammendrag og opplysninger i loggen, tidsstempelsvar, tidsstemplingstjeneste og tidspunkt, mislykkede forsøk (proof_docs).
Rettslig grunnlag	Personvernforordningen art. 6(1)(b).
Mottakere	Tidsstemplingstjenesten (standard Certum, reserve DigiCert) mottar bare hashen av loggen, ikke innholdet. Offentlig: nøkkeltall via bekreftelsessiden. Kunden og alle som Kunden gir loggen eller kontrollnummeret til.
Tredjeland	Ingen overføring av personopplysninger: En hash gjør det ikke mulig å trekke slutninger om innholdet. Reservetjenesten holder til i USA.
Lagring	Frem til domenet slettes (fe_domain_loeschen()). Tidsstempelet er ikke et kvalifisert tidsstempel etter eIDAS.
Tekniske og organisatoriske tiltak	Punkt 8.

B.20 Tillegg og utvidelse: kontroll, tilkobling og overføring

Felt	Oppføring
Formål	WordPress-tillegget og TYPO3-utvidelsen kan be om en kontroll (også uten konto), koble seg til en konto (installasjon teller som dokumentasjon på kontroll med ett klikk i kontoen), låse opp beskyttelsesfunksjoner, rapportere tall daglig (A.9) og rapportere e-postfeil og vedlikeholdsmodus umiddelbart.
Kategorier av registrerte	Kunder; nettstedoperatører som bruker tillegget uten konto.
Kategorier av personopplysninger	Per vert: tilleggs- og CMS-versjon, antall kontroller, siste rapportidentifikator, hash av tilkoblingshemmeligheten, første og siste kontakt (plugin_sites). Engangskoder for tilkobling som en hash med utløp (plugin_connect_tokens). Et byrås utrullingskoder som en hash med prefiks, etikett, bruk, opprettende person (workspace_connect_codes). Forespørselslogg med IP-adressen til serveren som kaller (B.4). Tilleggsnøkkelen er offentlig synlig i nettstedets hodedel; den er en hash av hemmeligheten, og selve hemmeligheten lagres bare som en hash og returneres aldri.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) (konto); uten konto (f) (bestilt kontroll, forebygging av misbruk).
Mottakere	Ingen.
Tredjeland	Ingen.
Lagring	En verts opplysninger forsvinner så snart ingen domener lenger viser til verten; raden for et tillegg uten konto først etter 90 dager uten kontakt (nattlig slettekjøring, delen «orphan_hosts»). Engangskoder én dag etter utløp. Utrullingskoder med arbeidsområdet.
Tekniske og organisatoriske tiltak	Punkt 8. Siden 27. september 2026 godtar serveren bare nøkkelpar som er bundet til nettstedet; eldre, ubundne tilkoblingshemmeligheter ble slettet.

B.21 Svermbeskyttelse

Felt	Oppføring
Formål	Felles spamforsvar: Tilkoblede nettsteder rapporterer domenene til lenker i meldinger som beskyttelseslaget har stoppet. Et domene som vises på minst tre nettsteder med minst fem treff innen sju dager, settes på en liste som går tilbake til alle tilkoblede nettsteder; beskyttelseslaget flytter meldinger med slike lenker til karantene, aldri til glemselen.
Kategorier av registrerte	Innehavere av de rapporterte lenkedomenene der de er fysiske personer (som operatøren av et spamnettsted under eget navn). Ikke avsenderne og mottakerne av meldingene: adresser, tekster og navn rapporteres ikke.
Kategorier av personopplysninger	Signaler: type, domene, rapporterende vert, dag, treff (swarm_signals). Liste: type, domene, antall nettsteder og treff, tidspunkter (swarm_list). Store tjenester, Kundenes domener og unntak satt av operatøren blir aldri oppført.
IP-nettverk	Deling av IP-nettverk (/24, /48) er forberedt. Den er slått av, og tillegget rapporterer ingen; den slås først på etter en juridisk gjennomgang, fordi IP-adresser er personopplysninger.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f). Interesse: Å beskytte alle Kundenes skjemaer mot spambølger. Avveining: Bare domener, minsteterskler mot forgiftning av listen, ingen tap av meldinger, fjerning mulig når som helst.
Mottakere	Alle tilkoblede nettsteder (domenelisten).
Tredjeland	Avhengig av hvor de tilkoblede nettstedene befinner seg; listen kan også nå nettsteder utenfor EØS. Den utgjør personopplysninger bare i grensetilfeller (fysiske personers domener). Overføringsgrunnlaget etter personvernforordningen kapittel V for disse tilfellene må fortsatt fastsettes (åpent spørsmål for den juridiske gjennomgangen).
Lagring	Signaler 30 dager (daglig svermkjøring fra 04:00, cfg/swarm_lib.php). Listen beregnes på nytt daglig; det som ikke lenger når terskelen, faller ut.
Tekniske og organisatoriske tiltak	Punkt 8.

B.22 API-nøkler, programmeringsgrensesnitt og MCP-server

Felt	Oppføring
Formål	Tilgang fra Kundens egne verktøy (REST API, Zapier, Make, MCP-server for KI-assistenter) til Kundens domener, kontroller og hendelser.
Kategorier av registrerte	Kunder som oppretter nøkler.
Kategorier av personopplysninger	Nøkkel bare som en hash, prefiks, etikett, tidspunkter for opprettelse, siste bruk og tilbakekalling (api_keys). Kall per minutt (api_usage).
Rettslig grunnlag	Personvernforordningen art. 6(1)(b).
Mottakere	Verktøyet Kunden utstyrer med nøkkelen; Kunden bestemmer det.
Tredjeland	Avhengig av Kundens verktøy.
Lagring	Nøkler frem til tilbakekalling, umiddelbart med kontoen; nøkler uten konto (eldre data) nattlig. Kalltellere etter én dag (ryddes opp av og til ved et kall).
Tekniske og organisatoriske tiltak	Punkt 8.

B.23 reCAPTCHA og vår egen skjemabeskyttelse

Felt	Oppføring
Formål	Forsvar mot automatisk tilgang til våre egne skjemaer: gratis kontroll, verktøy for HTTP-hoder, opt-out, innlogging, registrering, glemt og tilbakestilt passord, kundestøtte og kontakt. I tillegg vår egen beskyttelse uten tredjeparter: felle (skjult felt), signert tidskontroll og CSRF-token. Siden 29. oktober 2026 dessuten vår skjemabeskyttelse formconfirmed (beregningsbevis og kontrolltoken til engangsbruk) for den gratis kontrollen, registreringen, innloggingen og «glemt passord».
Kategorier av registrerte	Personer som sender inn disse skjemaene.
Kategorier av personopplysninger	Hos Google: IP-adresse, nettleser- og enhetsopplysninger, atferdsopplysninger, Google-informasjonskapsler. Hos oss: Googles vurdering (poengsum og handling) bare i kontrolløyeblikket, uten lagring, heller ikke når en innsending avvises. For vår egen skjemabeskyttelse: IP-adresse (lagres bare forkortet og hashet), side, tidspunkter, fellefelt utfylt ja/nei; ikke noe innhold.
Tidspunkt	Googles skript lastes bare når et beskyttet skjema sendes inn, ikke når siden åpnes. Vår egen skjemabeskyttelse henter oppgaven sin når siden åpnes, og regner så snart skjemaet tas i bruk. På utviklingssystemet er reCAPTCHA slått av.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f). Interesse: Beskyttelse mot boter, særlig for den gratis kontrollen, som ellers kunne brukes mot tredjepartsnettsteder. Om tilgang til terminalutstyret krever samtykke etter § 25 TDDDG eller art. 399 PKE, selv om skriptet bare lastes ved innsending, er et åpent spørsmål for den juridiske gjennomgangen. Vår egen skjemabeskyttelse setter ingen informasjonskapsler, lagrer ingenting i nettleseren og lager ikke noe fingeravtrykk; den skal på sikt erstatte reCAPTCHA.
Mottakere	Google Ireland Limited; Google LLC. For vår egen skjemabeskyttelse ingen.
Tredjeland	USA (bare reCAPTCHA). Grunnlag: sertifisering under EU-US Data Privacy Framework eller standard personvernbestemmelser; må dokumenteres i detalj.
Lagring	reCAPTCHA: ingen lagring hos oss; hos Google etter deres regler. Egen skjemabeskyttelse: hashet identifikator 1 time, brukte kontrolltokener høyst 11 minutter, kontrollresultater uten IP-adresse 30 dager.
Driftsavbrudd	Hvis Google ikke svarer innen tre sekunder eller gir et ubrukelig svar, avvises innsendingen; det samme gjelder en tom token og et svar for en annen handling enn skjemaets. Kontrollen hoppes over bare når reCAPTCHA er slått av. For vår egen skjemabeskyttelse avvises en innsending uten gyldig kontrolltoken; hvis tjenesten ikke var tilgjengelig for oppgaven, tillates den.
Tekniske og organisatoriske tiltak	Punkt 8.

B.24 Kundestøtte og kontaktskjema

Felt	Oppføring
Formål	Å motta og besvare henvendelser via kundestøttevinduet og kontaktsiden. Begge bruker samme behandlingsvei og tabell.
Kategorier av registrerte	Personer som henvender seg, innlogget eller ikke.
Kategorier av personopplysninger	Konto (hvis innlogget; kontoens adresse gjelder da, ikke den oppgitte), e-postadresse, årsak fra en fast liste, tekst inntil 4 000 tegn, status, fullstendig IP-adresse, land, nettleseridentifikator, henvisende side (bare egne stier), språk, tidspunkter for mottak og svar (support_requests); oppføring i aktivitetsloggen (uten tekst); mottaksbekreftelse til avsenderen i utboksen (B.25), med tekst inntil 2 000 tegn bare for innloggede avsendere, uten tekst for henvendelser uten innlogging.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) der henvendelsen gjelder en avtale; ellers (f). Fullstendig IP-adresse: (f) (grense på tre henvendelser per time og adresse, forebygging av misbruk).
Mottakere	E-postleverandør (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) for bekreftelse og svar. Telegram mottar et fast signal uten noen variabel («det finnes en ny henvendelse til kundestøtte») og dermed ingen personopplysninger.
Tredjeland	Via e-postleverandøren.
Lagring	24 måneder (nattlig slettekjøring, delen «support»); manuelt tidligere. Når en konto slettes, beholdes henvendelser frem til slutten av lagringstiden (punkt 6.4).
Tekniske og organisatoriske tiltak	Punkt 8. reCAPTCHA, vår egen skjemabeskyttelse, begrensning av forespørselsfrekvens.

B.25 Sending av e-post (utboks)

Felt	Oppføring
Formål	Transaksjons-e-poster: bekreftelse av registrering og nye e-postadresser, tilbakestilling av passord, invitasjoner, varsler, månedsrapporter, portalbekreftelser og rapporter, mottaksbekreftelser og svar fra kundestøtte, påminnelser om prøveperioden og oppsettet, driftsvarslinger til operatørene. Ingen reklame, ingen e-poster til personer som ikke selv har meldt seg på eller er oppgitt som mottakere av Kunden.
Kategorier av registrerte	Mottakere av disse e-postene.
Kategorier av personopplysninger	Mottakeradresse, emne, fullstendig innhold, svaradresse, formål, sendevei, status, feil, forsøk, tidspunkter (mail_outbox). Innholdet kan omfatte bekreftelses- og tilbakestillingslenker med gyldige identifikatorer.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b); for driftsvarslinger (f).
Mottakere	Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (sending); kontoinnehaveren ser sine sendte e-poster i dataeksporten (uten innhold).
Tredjeland	Avhengig av e-postleverandørens behandlingssted; avtale og overføringsgrunnlag må fortsatt dokumenteres (punkt 4).
Lagring	30 dager (nattlig, srv/cron_status.php). Denne perioden er bevisst den korteste av loggenes perioder: En lang sendelogg ville vært en samling gyldige nøkler. Statuskjøringen kontrollerer hvert femte minutt om et nytt forsøk skal gjøres.
Status	E-postsending må settes opp før lansering. Frem til e-postleverandøren med forretningssted og grunnlag er avklart, viser rettstekstene en markør.
Tekniske og organisatoriske tiltak	Punkt 8. Mislykkede e-poster forsøkes på nytt med økende intervaller og oppgis etter et maksimalt antall forsøk.

B.26 Betalinger og fakturering

Felt	Oppføring
Formål	Inngåelse og administrasjon av abonnementer (månedlig eller årlig på forskudd), 14 dagers prøveperiode uten kort med påminnelse tre dager før utløp, betaling mot faktura for årsabonnementer (av som standard), opplåsing via hosting- og partnerkoder uten betaling, fakturering, oppbevaring av skattemessige grunner.
Kategorier av registrerte	Kunder.
Kategorier av personopplysninger	Hos Stripe: e-postadresse, navn, faktureringsadresse, merverdiavgiftsnummer, betalingsopplysninger, fakturaer; som metadata konto-ID-en vår og abonnementet. Hos oss: Stripe-kunde- og abonnements-ID, abonnement, status, periodens slutt, oppsigelse ved periodens slutt (users); mottatte Stripe-hendelser bare med identifikator, type, status og tidspunkter, uten innhold (stripe_events); innløsninger av hostingkoder med konto, kampanje og utløp (bundle_redemptions). Kortopplysninger når aldri oss.
Kilde	Kunden i Stripes betalingsprosess; hendelser fra Stripe.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b); for oppbevaring av skattemessige grunner (c).
Mottakere	Stripe Payments Europe Limited (Irland); Stripe, Inc. (USA). For deler av betalingsbehandlingen handler Stripe under eget ansvar; den nøyaktige rollefordelingen er en del av den juridiske gjennomgangen.
Tredjeland	USA via Stripe, Inc.; grunnlag: Data Privacy Framework eller standard personvernbestemmelser etter Stripes vilkår.
Lagring	Faktureringsfelt med kontoen; et løpende abonnement avsluttes før kontoen slettes. Fakturaer og faktureringsdokumentasjon etter polsk skattelovgivning i fem år fra slutten av året da betalingsfristen for skatten utløp; de oppbevares hos Stripe og kan hentes i Stripe-kundeportalen. Stripe-hendelser og kodeinnløsninger har ingen lagringstid (punkt 6.4).
Tekniske og organisatoriske tiltak	Punkt 8. Stripe-hendelser godtas bare med gyldig signatur; hver hendelse behandles én gang.

B.27 Sikkerhetskopier

Felt	Oppføring
Formål	Gjenoppretting etter en feil: feilaktig sletting, skadet migrering.
Kategorier av registrerte	Alle som har opplysninger i databasen.
Kategorier av personopplysninger	Fullstendig, komprimert uttrekk av applikasjonsdatabasen. Skjermbilder og logofiler oppbevares utenfor databasen og er ikke en del av denne sikkerhetskopien. Testkontoens innloggingsopplysninger finnes i den bare som chiffertekst (A.5).
Fremgangsmåte	Nattlig kl. 03:00, etter slettekjøringen, slik at sikkerhetskopien ikke tar med det lagringstidene nettopp har slettet. Uttrekket beholdes først når innholdet er kontrollert (avslutningskode, antall tabeller, siste linje). På søndager laster en gjenopprettingstest den nyeste sikkerhetskopien inn i en midlertidig database og sammenligner den tabell for tabell. Hvis noe mislykkes, sendes et signal og en e-post til operatørene.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f) sammenholdt med art. 32(1)(c).
Mottakere	Ingen.
Tredjeland	Ingen.
Lagring	14 dager; eldre uttrekk fjernes først etter en vellykket ny sikkerhetskopi (cfg/backup_lib.php). Slettinger som skjer i denne perioden, når sikkerhetskopien først når den utløper; hvis opplysninger gjenopprettes fra en sikkerhetskopi, gjennomføres sletteanmodninger på nytt etterpå.
Sted	Sikkerhetskopiene oppbevares for tiden på samme sted som databasen og er ikke separat kryptert; en kryptert kopi på et annet sted er planlagt (punkt 8.1 og 10).
Tekniske og organisatoriske tiltak	Punkt 8.

B.28 Feillogg og feilvarsling

Felt	Oppføring
Formål	Å finne og rette feil før en Kunde melder dem. Nye feiltyper og feilbølger rapporteres til operatørene, i tillegg en daglig oversikt fra 08:00.
Kategorier av registrerte	Brukere hvis forespørsel forårsaker en feil; indirekte personer som har opplysninger i en feilmelding.
Kategorier av personopplysninger	Nivå, kilde, melding, kontekst som JSON, øktens konto-ID, tidspunkt (error_logs). Feiltyper: fingeravtrykk, mønster (der e-postadresser, adresser, tall og identifikatorer er fjernet), én uendret eksempelmelding på inntil 2 000 tegn, første og siste forekomst, antall (error_kinds).
Rettslig grunnlag	Personvernforordningen art. 6(1)(f) (driftssikkerhet, art. 32).
Mottakere	Operatørene per e-post via e-postleverandøren: for en ny feiltype kilde og råtekst i meldingen inntil 400 tegn (ikke renset), pluss den daglige oversikts-e-posten; ved en feilbølge sendes bare Telegram-signalet. Telegram mottar bare faste setninger uten variabler («En ny feiltype har oppstått», «Mange feil på kort tid»).
Tredjeland	Via e-postleverandøren.
Lagring	Feillogg 90 dager (nattlig). Feiltyper uten lagringstid (punkt 10). Feilvarslingen er på i produksjonssystemet og av i utviklingssystemet.
Tekniske og organisatoriske tiltak	Punkt 8.

B.29 Driftssignaler og statusovervåking

Felt	Oppføring
Formål	Å oppdage driftsavbrudd: hvert femte minutt kontroll av komponentene (startside, database, diskplass, skannerens livstegn, køetterslep), statusside, signal ved feil og ved klarsignal, livstegn til en ekstern overvåkingstjeneste slik at selv et fullstendig driftsavbrudd oppdages; etterslep foran skanneren.
Kategorier av registrerte	Som regel ingen.
Kategorier av personopplysninger	Ingen. Daglige rader per komponent med antall kontroller og siste feil (system_status_logs), skannerens livstegn (scanner_heartbeat), daglige nøkkeltall uten personreferanse (daily_stats). Signalene til Telegram er faste setninger uten variabler; livstegnet er en forespørsel uten innhold.
Rettslig grunnlag	Ikke relevant, siden det ikke finnes personopplysninger; som en forholdsregel art. 6(1)(f).
Mottakere	Telegram (faste setninger); den eksterne overvåkingstjenesten (bare forespørselen); operatørene per e-post.
Tredjeland	Telegram utenfor EU; ingen personopplysninger overføres.
Lagring	Statusrader 400 dager (nattlig).
Tekniske og organisatoriske tiltak	Punkt 8.

B.30 Opt-out – unnta et domene

Felt	Oppføring
Formål	Alle kan permanent unnta ethvert domene fra kontroller uten dokumentasjon; blokkeringen får umiddelbar virkning for alle kontrollveier (gratis kontroll, tillegg uten konto, studie, kontroll av potensielle kunder, verktøy for HTTP-hoder) og også for betalende Kunders domener med dokumentasjon på kontroll; deres løpende overvåking avsluttes ved neste planlagte kontroll. Den gjelder domenet og www-varianten, ikke andre underdomener. Den oppheves bare av oss, på forespørsel og med dokumentasjon. For at misbruk (som en konkurrent som blokkerer andres domener) skal kunne oppdages og reverseres, logges blokkeringen.
Kategorier av registrerte	Personer som unntar et domene.
Kategorier av personopplysninger	Domene, frivillig begrunnelse inntil 250 tegn, kilde, IP-adresse, land, nettleseridentifikator, tidspunkt; ved oppheving tidspunkt, personen som opphever blokkeringen og begrunnelse (blocklist). Forespørselslogg som B.4.
Rettslig grunnlag	For unntaket personvernforordningen art. 6(1)(f). Interesse: Å gjennomføre ønsket om at et domene ikke kontrolleres, permanent og på tvers av alle kontrollveier. Der personen som unntar domenet, selv er registrert, gjennomfører unntaket samtidig personens protest etter art. 21 (art. 6(1)(c)). For adresse, land og nettleseridentifikator (f) (oppdagelse av misbruk).
Mottakere	Google (reCAPTCHA, B.23).
Tredjeland	USA via reCAPTCHA.
Lagring	IP-adresse, land og nettleseridentifikator etter 12 måneder (nattlig slettekjøring, delen «optout_ip»). Selve unntaket forblir permanent, slik at det virker.
Tekniske og organisatoriske tiltak	Punkt 8. Mange blokkeringer fra ett land på kort tid genererer et avvik (B.4).

B.31 Påminnelse etter registrering

Felt	Oppføring
Formål	Én enkelt e-post to til 14 dager etter registrering til bekreftede kontoer uten bekreftet domene: «Legg til nettsted» eller «Bekreft domene». Intet tilbud, ingen pris, ingen oppgradering; med merknad om at den ikke sendes på nytt. Hverdager 09:00 til 18:00, høyst 50 per kjøring.
Kategorier av registrerte	Nye kontoinnehavere.
Kategorier av personopplysninger	E-postadresse, språk, sendetidspunkt (feltet «påminnelse sendt» i users), domene og bekreftelsesstatus.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) (merknad om oppsett av egen konto). Om e-posten regnes som kommunikasjon om avtaleforholdet eller som kommersiell informasjon som ville kreve samtykke (art. 10 UŚUDE, den polske loven om levering av tjenester elektronisk (ustawa o świadczeniu usług drogą elektroniczną); art. 398 PKE; § 7 UWG), er et åpent spørsmål for den juridiske gjennomgangen; operatøren kan slå den av sentralt.
Mottakere	E-postleverandør (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Tredjeland	Via e-postleverandøren.
Lagring	Tidspunktet finnes så lenge kontoen finnes; e-posten 30 dager i utboksen.
Tekniske og organisatoriske tiltak	Punkt 8. Tidspunktet settes før sending, slik at et avbrudd ikke utløser en e-post til.

B.32 Telegram-bot for Kundevarsler

Felt	Oppføring
Formål	En Telegram-chat kobles til som varslingsmottaker: Kunden får en lenke til boten vår med en engangskode; når mottakeren trykker «Start», leser serveren vår koden fra de nye meldingene til boten og lagrer chat-ID-en. Det trengs ikke noe åpent endepunkt på vår side (webhook) for dette.
Kategorier av registrerte	Kunder og personene som får Telegram-chatten sin tilkoblet.
Kategorier av personopplysninger	Engangskode, domene, opprettende konto, hendelser, leveringsmåte, chat-ID, tidspunkter (telegram_links); chat-ID-en som mottaker (alerts). Telegram leverer ytterligere profilopplysninger med meldingen; bare koden og chat-ID-en vurderes og lagres.
Rettslig grunnlag	Personvernforordningen art. 6(1)(b); for tredjeparter som mottakere A.3.
Mottakere	Telegram.
Tredjeland	Utenfor EU, ingen beslutning om tilstrekkelig beskyttelsesnivå; valget gjøres av Kunden (4.1). Grunnlag og informasjon er åpne spørsmål for den juridiske gjennomgangen.
Lagring	En kode er gyldig i 30 minutter; lenkerader slettes etter én dag når en ny kode opprettes, åpne koder med kontoen og domenet. Chat-ID-en som mottaker frem til varslingsmottakeren eller domenet slettes.
Tekniske og organisatoriske tiltak	Punkt 8.

B.33 Partnerprogram og opplåsingskoder

Felt	Oppføring
Formål	En konto kan henvise nye Kunder via en henvisningskode og får provisjon av de betalte fakturaene deres i et begrenset antall måneder. Koden følger med i adressen frem til registrering; ingen informasjonskapsel settes. Hostingleverandører og partnere kan utstede koder som låser opp et abonnement i en periode uten betaling; én uke før slutten får Kunden en påminnelse.
Status	Partnerprogrammet er av som standard frem til Partnervilkårene er på plass.
Kategorier av registrerte	Partnere og henviste Kunder.
Kategorier av personopplysninger	Henvisningskode, henvisende partner og henvisningstidspunkt (i users); provisjon med partner, Kunde, Stripe-faktura-ID, beløp, valuta, provisjon, status, tidspunkter (partner_commissions). Opplåsing med abonnement, slutt, kilde, påminnelse (i users); kampanjer og innløsninger (bundle_campaigns, bundle_redemptions).
Rettslig grunnlag	Personvernforordningen art. 6(1)(b) (partneravtale); for Kunden (f) (provisjonsoppgjør, uten å gi Kundens opplysninger til partneren ut over provisjonsbeløpet); skattedokumentasjon (c).
Mottakere	Partneren ser provisjonene sine.
Tredjeland	Ingen.
Lagring	Henvisning og opplåsing med kontoen. Provisjoner og innløsninger har ingen lagringstid i koden; som regnskapsdokumentasjon er provisjoner underlagt skattemessig oppbevaringsplikt (punkt 6.4).
Tekniske og organisatoriske tiltak	Punkt 8.

B.34 Rapporteringspunkt for sårbarheter

Felt	Oppføring
Formål	Å motta rapporter om sårbarheter i formexposed etter reglene på siden Sikkerhet og i /.well-known/security.txt.
Kategorier av registrerte	Personer som rapporterer; personer som har opplysninger i en rapport som dokumentasjon.
Kategorier av personopplysninger	E-postadresse, navn, rapportens innhold og vedlegg, slik personen sender dem. Rapporten når oss per e-post til adressen som er oppgitt der; applikasjonen lagrer den ikke.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f) (tjenestens sikkerhet, art. 32); der en rapport inneholder tredjeparters personopplysninger som dokumentasjon, også (f), med sikte på å lukke sårbarheten.
Mottakere	E-postleverandør og, frem til postkassen er satt opp, domenevideresendingen hos Namecheap (punkt 4).
Tredjeland	Via e-postleverandøren og frem til omleggingen videresendingen.
Lagring	Ingen lagringstid er fastsatt eller teknisk håndhevet (punkt 10). Operatøren må fortsatt fastsette perioden; en nærliggende fremgangsmåte ville være å slette tredjepartsdokumentasjon når sårbarheten er lukket og behandle korrespondansen som henvendelser til kundestøtte.
Tekniske og organisatoriske tiltak	Punkt 8.

B.35 Tilbakemelding på en rapport

Felt	Oppføring
Formål	Å motta tilbakemeldinger under en rapport («Er noe feil i denne rapporten?») for å finne feil i skjemagjenkjenningen. Superadministratoren klassifiserer dem (ny, bekreftet, rettet, avvist) og kan laste ned rapportens kontrolldata som et testtilfelle (skjemaer med felt, årsaker og funn, uten skjermbilder og uten aktivt sendte tekster).
Kategorier av registrerte	Personer som ser på en rapport, innlogget eller ikke.
Kategorier av personopplysninger	Kategori og kontroll fra faste lister, sideadresse inntil 500 tegn, tekst inntil 1 000 tegn, språk, tidspunkt, rapportidentifikator, kontroll, vert; kontoidentifikator hvis innlogget; HMAC-SHA256 av IP-adressen med en hemmelig nøkkel for grensen; status, saksbehandler, behandlingstidspunkt (report_feedback). Aktivitetslogg: statusendringer og nedlastinger av et testtilfelle. Ingen e-postadresse, ingen IP-adresse i klartekst.
Rettslig grunnlag	Personvernforordningen art. 6(1)(f) (finne og rette gjenkjenningsfeil; grense mot misbruk).
Mottakere	Ingen.
Tredjeland	Ingen.
Lagring	24 måneder (nattlig slettekjøring, delen «report_feedback»); kontrollsummen av IP-adressen fjernes etter 2 dager (delen «report_feedback_ip»); umiddelbart når en konto slettes. Nedlastede testtilfeller inneholder ingen opplysninger om personen som rapporterer.
Tekniske og organisatoriske tiltak	Punkt 8. Egen skjemabeskyttelse (felle, signert tid, CSRF), høyst 5 meldinger per time og 20 per dag per kontrollsum, 10 per rapport; kan bare leses av superadministratorer.

6. Lagring – hva den nattlige slettekjøringen omfatter og hva den ikke omfatter

Det finnes automatisk sletting, og den har et sted. En statuskjøring (srv/cron_status.php) startes hvert femte minutt via nettserverens crontab, både på produksjons- og utviklingssystemet. Den kontrollerer komponentene, henter e-posten fra leveringskontrollen, planlegger kontroller og sender varsler. Én gang om dagen, i vinduet fra 03:00 til 03:04, sletter den etter lagringstidene og oppretter deretter sikkerhetskopien. Siden 27. september 2026 har den i tillegg kalt lagringskjøringen i cfg/fristen_lib.php (fe_fristen_lauf()), der delene kjører uavhengig av hverandre: Hvis én mislykkes, fortsetter de andre, og feilen registreres i feilloggen.

Dokumentasjon på at kjøringen går: Sikkerhetskopistatusen på utviklingssystemet viser en vellykket sikkerhetskopi kl. 03:00 den 11. oktober 2026; sikkerhetskopien opprettes i samme blokk umiddelbart etter slettingen. Kjøringen skriver en logg per slettet tabell bare til standard utdata, som crontab forkaster; det finnes ingen varig dokumentasjon på hva som ble slettet når (punkt 10).

Lagringstidene som vises som plassholdere, stilles inn i administrasjonsområdet under lagringsinnstillingene. Kjøringen leser de samme innstillingene; tekstene viser derfor alltid perioden som opplysninger faktisk slettes etter.

6.1 Omfattet av den daglige kjøringen

Opplysninger	Lagringstid og utløser	Sted i koden
Sidevisningslogg (access_logs)	60 dager	srv/cron_status.php
Aktivitetslogg (audit_logs)	365 dager	srv/cron_status.php
Feillogg (error_logs)	90 dager	srv/cron_status.php
Utboks (mail_outbox)	30 dager	srv/cron_status.php
Husk-meg-tokener for «Hold meg innlogget» (remember_tokens)	etter utløp (30 dager)	srv/cron_status.php
Ikke godtatte invitasjoner (workspace_invites)	etter utløp (14 dager)	srv/cron_status.php
Innloggingsforsøk (login_attempts); forsøkstellere (auth_attempt_buckets)	7 dager; tellere når tidsvinduet utløper (for tiden 15 minutter, én time for tilbakestilling av passord og registrering), også ved neste tilgang	srv/cron_status.php
Forespørselslogg for kontroller uten konto (check_throttle)	7 dager	srv/cron_status.php
Engangskoder for tilkobling av tillegget (plugin_connect_tokens)	1 dag etter utløp	srv/cron_status.php
Løste avvik (abuse_flags)	90 dager etter løsning	srv/cron_status.php
Utløpte rapporter sammen med kontrollresultat, skjemaer, funn, bilder og jobb (bare uten domene i en konto)	anonyme 30 dager, potensielle kunder 90 dager	fe_reports_aufraeumen()
Leveringslogg for varsler (alert_log)	90 dager	fe_alert_log_aufraeumen()
Statusrader (system_status_logs)	400 dager	srv/cron_status.php
Samtykkeregistreringer for slettede kontoer (legal_consents)	når kontoen er slettet og samtykket er 4 år gammelt	srv/cron_status.php
Foreldreløse data etter slettede domener: kontrollresultater, jobber, varslingsdata, hendelser, Telegram-koder, leveringer, puls, sårbarheter, dokumentasjon, skriptoversikt og skriptendringer	umiddelbart ved neste kjøring	fe_fristen_lauf(), delene «orphan_scans», «orphan_rows»
Tilleggsopplysninger for verter uten domene; tilleggsrad uten konto	umiddelbart; rad etter 90 dager uten kontakt	delen «orphan_hosts»
Resultater fra verktøyet for HTTP-hoder (header_checks)	for tiden 90 dager	delen «header_checks»
Kontrollresultater for et domene med skjemaer, funn, bilder, rapporter, jobber	13 måneder; den siste fullførte per domene beholdes	delen «old_scans»
Nettleserkjøringer, fullførte nettleserjobber, tidsserier (form_browser_runs, scan_jobs, form_performance)	13 måneder	delene «browser_runs», «browser_jobs», «form_performance»
Skjematellere (form_metrics), daglige tilleggsverdier og endringsmeldinger (plugin_stats, plugin_changes)	13 måneder	delene «form_metrics», «plugin_stats»
Innloggede enheter (login_sessions)	90 dager etter siste bruk eller tilbakekalling	delen «sessions»
Godtatte invitasjoner	30 dager etter aksept	delen «invites»
Henvendelser til kundestøtte (support_requests)	24 måneder	delen «support»
Tilbakemeldinger på rapporter (report_feedback)	24 måneder; kontrollsum av IP-adressen 2 dager	delene «report_feedback» og «report_feedback_ip»
PDF-versjoner av rapporter i hurtigbufferen (var/pdf)	7 dager	delen «pdf_cache»
IP-adresse, land og nettleseridentifikator i opt-out (blocklist)	12 måneder; unntaket består	delen «optout_ip»
Portalabonnenter (client_subscribers)	ubekreftede 30 dager; avmeldte 3 år	delen «subscribers»
Kontoer som aldri er bekreftet, sammen med arbeidsområdet	30 dager uten innlogging, med mindre et annet medlem er tilknyttet	delen «pending_accounts»
API-nøkler uten konto (eldre data)	umiddelbart	delen «api_keys»

6.2 Utenfor 03:00-vinduet

Opplysninger	Lagringstid og utløser	Sted i koden
Kopier i leveringskontrollens kontrollpostkasse	etter behandling, hvert femte minutt	fe_zustellung_abholen()
Tilordninger i leveringskontrollen (delivery_log)	180 dager, ved hver henting	fe_zustellung_abholen()
Testkontoens chiffertekst i jobber (scan_jobs)	etter kjøringen, senest etter én time	skanneserver; fe_login_aufraeumen()
Hendelser (alert_incidents) med leveringsforsøk ved eskalering	så lenge uløst; 180 dager etter løsning	fe_vorfaelle_aufraeumen() i cfg/vorfall_lib.php
Sendte sammendragsvarslinger (alert_queue)	30 dager etter levering	cfg/kanal_lib.php
Svermsignaler (swarm_signals)	30 dager, daglig fra 04:00	cfg/swarm_lib.php
Kontroller av potensielle kunder (prospect_checks)	90 dager, daglig fra 04:00	srv/cron_status.php
Telegram-tilkoblingskoder (telegram_links)	1 dag, når en ny kode opprettes	cfg/kanal_lib.php
API-kalltellere (api_usage)	1 dag, av og til ved et kall	cfg/agentur_lib.php
Løste driftsavbrudd hos leverandører (provider_incidents), sårbarhetshurtigbuffer (vuln_cache)	henholdsvis 90 og 30 dager; ingen personopplysninger	cfg/anbieter_lib.php, cfg/luecken_lib.php
Studiens rådata	ved publisering	fe_studie_veroeffentlichen()
Sikkerhetskopier	14 dager, etter en vellykket ny sikkerhetskopi	cfg/backup_lib.php
Nettserverlogger	14 dager	systemets loggrotasjon

6.3 Ved sletting fra Kundens side

• Slette et domene (fe_domain_loeschen()): kontrollresultater med skjemaer, funn og bildefiler, rapporter, jobber, varslingsmottakere, leveringslogg, sammendragskø, hendelser, Telegram-koder, leveringer, puls, sårbarheter, dokumentasjonslogger, domenet fra kundeportaler med et fast utvalg; via fremmednøkler overvåkede skjemaer med nettleserkjøringer, observasjoner og tidsserier, testkonto, skjematellere; vertens tilleggsopplysninger hvis intet annet domene viser til den. Domenets skriptoversikt og skriptendringer slettes også sammen med det; de har ingen egen lagringstid (punkt 6.4 og 10). Opplysninger som er igjen uten tilknyttet domene fra tiden før 27. september 2026, fjernes av den nattlige kjøringen (delene «orphan_scans», «orphan_rows»).
• Slette et arbeidsområde (fe_arbeitsbereich_daten_loeschen()): i tillegg merkevare inkludert logo, kundeportaler inkludert abonnenter, utrullingskoder, kontroller av potensielle kunder; samt invitasjoner og medlemskap.
• Slette en konto: avslutte et løpende betalt abonnement hos Stripe umiddelbart uten refusjon; overføre eller slette innehaverens egne arbeidsområder; slette medlemskap, husk-meg-tokener, enheter, API-nøkler med tellere, åpne Telegram-koder og kontoraden.
• Slette en testkonto (fe_login_loeschen()): overskrive chifferteksten, slette raden, tømme ventende jobber.

6.4 Hva kjøringen ikke omfatter

Denne listen er den viktigste. Den oppgir opplysninger som ikke har noen automatisk lagringstid, eller som beholdes etter en sletting.

Opplysninger	Hva som gjelder	Vurdering
Kontoopplysninger inkludert siste IP-adresse (users)	frem til kontoinnehaveren sletter kontoen; ingen sletting av inaktive kontoer	avtaleopplysninger; en regel for varig inaktive kontoer uten abonnement mangler
Aktivitetslogg, sidevisninger, feillogg for en slettet konto	beholdes med konto-ID og IP-adresse frem til slutten av lagringstiden	tilsiktet (dokumentasjon på handlinger også etter opphør); ID-en peker ikke lenger til en konto
Henvendelser til kundestøtte fra en slettet konto	beholdes i inntil 24 måneder med den gamle konto-ID-en	tilsiktet; ID-en fjernes ikke
Samtykkeregistreringer for en slettet konto	frem til samtykket er 4 år gammelt (regnet fra samtykket, ikke fra kontoslettingen)	tilsiktet (punkt B.12)
Uløste avvik med IP-adresse (abuse_flags)	frem til noen løser dem	åpent spørsmål (punkt 10)
Feiltyper med uendret eksempelmelding (error_kinds)	ingen lagringstid	åpent spørsmål (punkt 10)
Skriptoversikt og skriptendringer (script_inventory, script_changes)	ingen egen lagringstid; beholdes så lenge domenet finnes og slettes med det	åpent spørsmål (punkt 10)
Abonnenter i tilbakekalte kundeportaler	frem til arbeidsområdet slettes	åpent spørsmål (punkt 10)
Tilbakekalte API-nøkler og utrullingskoder	frem til kontoen eller arbeidsområdet slettes	bare hasher, prefiks og etikett; mindre betydning
Liste over studieverter (study_domains), studier som aldri publiseres	ingen lagringstid	åpent spørsmål (punkt 10)
Interne kontroller uten domene og uten rapport (kontrollresultater, skjemaer, funn, skjermbilder)	ingen lagringstid; ingen slettevei omfatter dem	åpent spørsmål (punkt 10)
Provisjoner, kodeinnløsninger, Stripe-hendelser	ingen lagringstid	regnskapsmessig relevans; perioden må fastsettes etter skattelovgivningen
Mellomlagret domenealder (domain_age_cache)	ingen lagringstid	bare domenenavn og registreringsdato
Autentiseringsresultat for skjema-e-posten med avsenderdomene	med domenet; overskrives ved hvert mottak	se A.1
Unntak i opt-out	permanent	tilsiktet; uten varighet virker ikke noe unntak
E-poster i rapporteringspunktets postkasse og den generelle postkassen	ingen teknisk lagringstid	åpent spørsmål (punkt 10)

6.5 Utenfor databasen

• Skjermbilder oppbevares som filer utenfor nettkatalogen og slettes med kontrollresultatet (alle sletteveiene ovenfor sletter også filene).
• Logofiler for merkevaren slettes når de erstattes og med arbeidsområdet.
• På skanneserveren opprettes en midlertidig katalog med resultat og bilder per jobb; den slettes etter hver kjøring, også etter en feil.
• Sikkerhetskopier oppbevares på nettserveren (B.27).
• Nettserverlogger med fullstendig IP-adresse beholdes i 14 dager (B.1).

7. Automatiserte avgjørelser, profilering og vurdering

formexposed vurderer nettsteder, ikke mennesker. Etter vår vurdering tar tjenesten ingen avgjørelse som har rettsvirkning for en person eller på tilsvarende måte i betydelig grad påvirker vedkommende (personvernforordningen art. 22(1)). Det finnes imidlertid automatiserte vurderinger og automatiske blokkeringer. Vi oppgir dem slik at klassifiseringen kan kontrolleres.

Mekanisme	Hva den gjør	Hvem den berører
Poengsum og vurdering av en kontroll	Vektet sum av manglende beskyttelseslag (CAPTCHA, felle, token, tidskontroll, ineffektiv CAPTCHA, kjent tilgjengelig konfigurasjon), 0 til 100; fra dette «Ubeskyttet», «Delvis beskyttet» eller «Beskyttet». Nettstedets vurdering følger det svakeste kontaktskjemaet som reglene gjenkjenner som slikt (ikke språkmodellen); uten et kontaktskjema finnes ingen vurdering. Vektene kan stilles inn i administrasjonsområdet.	Nettstedoperatører; for enkeltpersonforetak indirekte en person. Vurderingen har ingen rettslig følge; den er et funn med dokumentasjon og veiledning.
Klassifisering av skjematypen	Regler først, en lokal språkmodell bare hvis reglene gir «unknown». Avgjør om en aktiv testinnsending er tillatt (bare for et kontaktskjema reglene gjenkjenner med sikkerhet). Skjemaer som klassifiseres av språkmodellen, sendes det aldri inn gjennom, og de teller ikke med i poengsum og vurdering.	Kunden og mottakerne av Kundens skjema-e-poster; beskyttende virkning: ved tvil sendes ingenting inn.
Prioritert tiltaksplan i betalte rapporter	En lokal språkmodell oppsummerer utvalgte mislykkede eller uklare funn og skannemetadata som korte, nummererte trinn. Teksten merkes som en KI-oppsummering; enkeltfunnene er fortsatt avgjørende. Den endrer ingen skannepoengsum, vurdering eller nettstedskonfigurasjon.	Kunden eller en annen autorisert rapportleser, som bestemmer hvilke trinn som skal gjennomføres.
Merke	Viser «Beskyttet» bare under faste vilkår (B.18), ellers nøytralt.	Kunden; ingen virkning for besøkende.
Grenser og blokkeringer for gratis kontroll, verktøy for HTTP-hoder og opt-out	Avviser forespørsler hvis grenser per adresse, økt, domene eller system er nådd, hvis domenet er for ungt eller har ukjent alder, eller hvis det står på blokkeringslisten.	Personer som sender forespørsler; virkning: en gratistjeneste avslås i timer til dager. En administrator kan frigi en adresse; henvendelser via kontaktsiden når et menneske.
Avvik	Mønstre (mange domener fra én adresse, forespørselsbølger, mange avvisninger, mange opt-out fra ett land, dagsgrense nådd) registreres og rapporteres. De blokkerer ikke i seg selv; blokkering følger av grensene.	Personer som sender forespørsler.
Innloggingssperre	Etter for tiden åtte mislykkede innlogginger fra én adresse innen 15 minutter avvises innlogginger fra denne adressen midlertidig. I tillegg telles alle innloggingsforsøk, inkludert vellykkede, per konto og IP-adresse (for tiden åtte), per konto på tvers av alle adresser (betydelig flere, mot distribuert gjetting) og per IP-adresse (for tiden 80) innen 15 minutter, og det samme gjelder koder for andre faktor (ti per konto innen 15 minutter); ut over dette avvises forsøk. Mislykkede forsøk fra en annen adresse låser dermed ikke lenger eieren ute av en konto. Passordbekreftelser (fem per konto innen 15 minutter), tilbakestillings-e-poster (tre per adresse per time, med uendret svar), registreringer (ti per IP-adresse per time) og forsøk på passordet til en kundeportal (ti per portal og IP-adresse, 50 per portal innen 15 minutter) begrenses på samme måte.	Personer som logger inn, registrerer seg eller åpner en kundeportal; virkningen er tidsbegrenset, tilbakestilling av passord er fortsatt mulig.
reCAPTCHA-terskel	Avviser innsendinger under en Google-poengsum; terskel per brukssted (for tiden 0,7 for kontroll og opt-out). Svar for en annen handling og innsendinger der Google ikke svarer innen tre sekunder, avvises også.	Personer som sender inn skjemaene våre; virkning: et nytt forsøk eller veien via kontaktsiden.
Svermbeskyttelse	Setter automatisk et lenkedomene på en liste når minsteterskler nås; beskyttelseslagene på tilkoblede nettsteder flytter meldinger med slike lenker til karantene.	Avsendere av meldinger til Kundesider. Virkning: Meldingen holdes tilbake, slettes ikke, og kan frigis av nettstedoperatøren. Avgjørelsen om meldingen tas av operatørens tillegg på operatørens nettsted, ikke av oss.
Sammenligningsverdier	«Bedre beskyttet enn X % av kontrollerte nettsteder», bare fra samlede tall for minst 20 verter.	Nettstedoperatører; ingen virkning.

Det nærmeste man kommer art. 22, er tilleggets beskyttelseslag på Kundesider, som automatisk holder tilbake innsendinger. Det er behandling utført av nettstedoperatøren på operatørens server (A.10). Det sletter ingenting, men flytter meldinger til karantene, og operatøren kan frigi enhver melding. Ingen profilering av besøkende skjer der eller hos oss; det finnes ingen besøksidentifikator som knytter én melding til en annen.

8. Tekniske og organisatoriske tiltak (art. 32) – generell beskrivelse

Dette punktet er den generelle beskrivelsen etter personvernforordningen art. 30(1)(g) og (2)(d). Den detaljerte versjonen finnes på siden Tekniske og organisatoriske tiltak. Hvert tiltak nedenfor er dokumentert i koden eller konfigurasjonen. Tiltak som ennå ikke er gjennomført, står i samme punkt (8.1), slik at beskrivelsen er fullstendig.

Område	Tiltak som er i kraft
Transportkryptering	HTTPS for nettsted, applikasjon og grensesnitt; HSTS; økt- og husk-meg-informasjonskapsler bare over HTTPS, HttpOnly, SameSite=Lax.
Tilgangskontroll (autentisering)	Passord bare som en hash, nye med minst ti tegn og høyst 72 byte; innloggingssperre etter gjentatte mislykkede forsøk og forsøksgrenser per konto og IP-adresse sammen, per konto og per IP-adresse, slik at mislykkede forsøk fra en annen adresse ikke låser eieren ute; forsøksgrenser også for passordbekreftelser, tilbakestilling av passord (med samme svar og svartid), registreringer og portalpassord; tofaktorinnlogging (TOTP) med kryptert hemmelighet, beskyttelse mot gjenbruk av koder og hash-lagrede gjenopprettingskoder; ny øktidentifikator ved hver innlogging, identifikatorer som ikke er utstedt av serveren, godtas ikke; «Hold meg innlogget» ikke for superadministratorer, hver token gyldig bare én gang; endring av e-postadressen ugyldiggjør en åpen tilbakestillingslenke; enheter kan tilbakekalles enkeltvis eller alle på én gang; enhetslisten inneholder bare hashen av øktidentifikatoren.
Tilgangskontroll (autorisasjon)	Roller per arbeidsområde (eier, administrator, leser); rettigheter kontrolleres mot objektet, aldri mot en identifikator fra skjemaet; testkonto, «Fix it for me» og aktive kontroller bare for eiere og administratorer; «Vis som Kunde» tidsbegrenset og blokkert for handlinger som endrer kontoen, avslutning logger helt ut, retur til administrasjonsområdet bare med passord og andre faktor; invitasjoner gyldige bare så lenge inviterende person er eier eller administrator; adresser til webhooks og chatkanaler vises til lesere bare forkortet til verten; vertsnavnet til et verifisert domene kan ikke endres.
Applikasjonssikkerhet	CSRF-tokener; forberedte databasesetninger; egen skjemabeskyttelse (felle, signert tidskontroll); reCAPTCHA på offentlige skjemaer; begrensning av forespørselsfrekvens for kundestøtte, kontroller og grensesnitt; bare ett «Fix it for me»-kall per arbeidsområde om gangen, slik at kvoten også gjelder ved samtidige forespørsler; innholdssikkerhetspolicy med innrammingsbeskyttelse som bare tillater skript med godkjenningen (nonce) til det aktuelle svaret; IP-adresse fra videresendte hoder bare fra vår egen proxy og bare fra oppføringen den har lagt til; tilgangstokener maskert i sidevisningsloggen.
Hemmeligheter	API-nøkler, utrullingskoder, tilkoblingshemmeligheter for tillegg, engangskoder og portalpassord bare som en hash; testkontoens innloggingsopplysninger asymmetrisk kryptert, privat nøkkel bare på skanneserveren; webhooks signert; Stripe-hendelser bare med gyldig signatur.
Dataminimering	Leveringskontrollen lagrer ikke innhold eller fullstendige avsenderadresser; mottakeradresser i skjemaer bare som et domene; konto-ID-er i skriptadresser erstattes; tilleggstall bare fra faste lister; feiltekster fra e-postsending bare som kategori; Telegram-signaler uten variabler; bilder fra nettleserkontroll med maskerte inndata; ingen skjermbilder bak innlogging.
Isolering av skanneren	Hver kontroll i egen container: alle Linux-kapabiliteter fjernet, ingen eskalering av rettigheter, skrivebeskyttet filsystem, minne- og prosessgrense, eget nettverk; målkontroll mot private og lokale nettverk før mottak og i skanneren, også etter omdirigeringer; service workers blokkert, WebSocket-tilkoblinger lukket. Forespørsler fra nettserveren (dokumentasjon på kontroll, verktøy for HTTP-hoder, filsøk, puls, RDAP, sertifikater, webhooks og chatvarsler) bare på vanlige nettporter og bare til nøyaktig den kontrollerte adressen, webhooks og chatvarsler bare over HTTPS.
Lagring	Skjermbilder utenfor nettkatalogen, kan bare hentes via rapporten; rapporter på tilfeldige adresser med noindex; sikkerhetskopikatalogen kan bare leses av tjenesten.
Tilgjengelighet og gjenoppretting	Nattlig sikkerhetskopi med innholdskontroll, ukentlig gjenopprettingstest, varsel ved feil; komponentkontroll hvert femte minutt med signal og e-post; eksternt livstegn; nødstopp for anonyme kontroller; kapasitetsstyring ved etterslep.
Sporbarhet	Aktivitetslogg for innlogginger, endringer, slettinger, kundestøttetilgang og godkjenninger; feillogg med varsling.
Sletting	Lagringstider på ett sted i koden, fra samme innstillinger som tekstene (punkt 6); slettekjeder for domene, arbeidsområde og konto, med unntakene i punkt 6.4.
De registrertes rettigheter	Eksport med ett klikk av alle kontoopplysninger som en fil, basert på en tillatelsesliste over felt, uten hemmeligheter.
Organisering	Administrasjonsområde bare for kontoer med superadministratorrettigheter, blokkert under «Vis som Kunde»; utviklings- og produksjonssystemer atskilt, utviklingssystemet bak en ytterligere tilgangssperre; overføring av rettstekster etter godkjenning via et verktøy som avviser utkast og plassholdere.

8.1 Tiltak som ennå ikke er gjennomført

• Ingen kryptering av databasen i hvile (målt 11. oktober 2026). Unntakene er testkontoens innloggingsopplysninger og hemmeligheten for andre faktor, som er kryptert på feltnivå.
• Interne tilkoblinger ikke gjennomgående kryptert. Tilkoblinger i det interne nettverket vårt er ikke gjennomgående kryptert. Testkontoens innloggingsopplysninger overføres der bare som chiffertekst.
• Ingen sikkerhetskopi på et annet sted. Sikkerhetskopiene oppbevares for tiden på samme sted som databasen og er ikke separat kryptert; en kryptert kopi på et annet sted er planlagt. Frem til da beskytter de mot en feil slettekommando, ikke mot tap av hele stedet.
• Herding av serveradministrasjonen ikke fullført. Sikkerheten ved den administrative tilgangen til serverne våre oppfyller ennå ikke standarden vi sikter mot for drift; herdingen fortsetter. Vi publiserer ikke detaljer fordi de ville hjelpe en angriper; vi gir dem til en tilsynsmyndighet på forespørsel.
• Ingen funksjonell leselogg i administrasjonsområdet. Skrivehandlinger registreres i aktivitetsloggen; hvem som bare så på hvilken henvendelse til kundestøtte eller hvilken rapport, kan bare fastslås fra sidevisningsloggen (60 dager).
• Ingen varig slettelogg. Det den nattlige kjøringen har slettet, registreres ikke (punkt 6).
• Intet uavhengig andre kontrollpunkt. Kontrollinstansen på et annet sted er ikke satt opp (A.6).

9. Personvernombud – vurdering etter personvernforordningen art. 37

Resultat: Etter vår vurdering foreligger ingen plikt til å utpeke et. Vurderingen er en del av den juridiske gjennomgangen og gjentas så snart noen av omstendighetene nedenfor endrer seg.

Art. 37(1) krever utpeking i tre tilfeller.

• Bokstav (a) (offentlig myndighet eller organ) gjelder ikke.
• Bokstav (b) (kjernevirksomhet som krever regelmessig og systematisk monitorering av registrerte i stor skala): Kjernevirksomheten vår er regelmessig, systematisk kontroll av nettsteder og skjemaer, ikke observasjon av mennesker. Vi oppretter ingen besøksprofiler, bruker ingen sporing og knytter ingen melding til en annen. Leveringskontrollen (A.1) lar reelle besøksmeldinger passere gjennom postkassen vår, men vurderer bare hoder og de første 8 KB for tilordning og lagrer ikke innhold; den observerer leveringsveier, ikke mennesker. Kundekontoer og logger er støttefunksjoner for virksomheten.
• Bokstav (c) (behandling i stor skala av særlige kategorier etter art. 9 eller opplysninger om straffbare forhold etter art. 10 som kjernevirksomhet): Ikke oppfylt. Særlige kategorier kan forekomme tilfeldig i kopier av skjema-e-poster (A.1), på sider bak innlogging (A.5) eller i innlimt kode (A.7); tilfeldig innsamling er ikke kjernevirksomhet.

Art. 37(4) tillater at nasjonal rett tilføyer flere tilfeller. Vi får bekreftet av en advokat om polsk rett krever at vi utpeker et.

Utløsere for en ny vurdering: Aktivering av svermbeskyttelse med IP-nettverk; en funksjon som gjenkjenner besøkende på tvers av flere meldinger eller nettsteder; lagring av innhold fra leveringskontrollen; en Kunde der skjemaene hovedsakelig gjelder særlige kategorier (helse, jobbsøknader), med leveringskontrollen slått på i stor skala; den første ansatte med tilgang til kundeopplysninger. Frivillig utpeking er fortsatt mulig; art. 37 til 39 gjelder da fullt ut.

Separat: Om en vurdering av personvernkonsekvenser etter art. 35 kreves for enkelte behandlingsaktiviteter, besvares på siden Vurdering av personvernkonsekvenser. Terskelvurderingen der konkluderer med at en slik vurdering kreves for svermbeskyttelse (B.21) og studier i tiltenkt skala (B.7) og utføres av oss, og at den for leveringskontrollen (A.1) kreves i den typiske situasjonen som en plikt for Kunden, som vi bistår med dette.

10. Åpne spørsmål og planlagte tiltak

Følgende punkter er dokumentert i koden, skjemaet eller konfigurasjonen, ikke antatt. De beskriver stillingen på datoen for denne versjonen; klassifiseringen er vår egen og foregriper ingen rettslig vurdering. De er ordnet etter betydningen for de registrerte, ikke etter hvor lette de er å rette. De planlagte tiltakene og prioriteten er angitt i Vurdering av personvernkonsekvenser.

Åpent spørsmål	Hva som er dokumentert	Betydning
E-postleverandør uten dokumentert avtale	For Namecheap, Inc. (Private Email), Phoenix, Arizona, USA er avtalen, behandlingsstedene og overføringsgrunnlaget ikke dokumentert. Konto-e-poster, varsler og kontrollpostkassen med reelle besøksmeldinger går gjennom denne leverandøren.	De relevante bestemmelsene er personvernforordningen art. 28(2) og (4) og kapittel V. Inngåelse og dokumentasjon er planlagt før lansering.
Grunnlag for chattjenester og reCAPTCHA uavklart	Varsler til Telegram (ingen beslutning om tilstrekkelig beskyttelsesnivå), Slack, Discord, Microsoft Teams og Google Chat; reCAPTCHA uten forespørsel om samtykke.	Åpne spørsmål for den juridiske gjennomgangen; frem til da er informasjon og grunnlag ikke endelige.
Kontrollpostkassen kan beholde meldinger ved driftsforstyrrelser	Sletting skjer etter vellykket behandling; hvis hentingen mislykkes, beholdes kopiene frem til neste vellykkede kjøring. Det finnes ingen advarsel når et etterslep bygger seg opp i postkassen over lengre tid.	Kopiene inneholder reelle besøkshenvendelser.
Ingen sikkerhetskopi på et annet sted, ingen kryptering av databasen i hvile	Punkt 8.1. En kryptert kopi av sikkerhetskopien på et annet sted er planlagt.	Én hendelse på stedet ville ramme opplysninger og sikkerhetskopi samtidig; et stjålet lagringsmedium ville være lesbart.
Uløste avvik uten lagringstid	Avvik med fullstendig IP-adresse som nøkkel slettes først 90 dager etter løsning; det som aldri løses, beholdes.	Gjelder prinsippet om lagringsbegrensning (art. 5(1)(e)); sletting avhenger av manuell løsning. En fast lagringstid er planlagt (tiltakene i Vurdering av personvernkonsekvenser).
Feiltyper med eksempelmelding uten lagringstid	Eksempelmeldingen lagres uendret inntil 2 000 tegn; det rensede mønsteret fjerner adresser og tall, eksemplet gjør det ikke.	Feilmeldinger kan inneholde e-postadresser, vertsnavn eller IP-adresser.
Skriptoversikt uten egen lagringstid	Skriptoversikt og skriptendringer slettes med domenet (FE_DOMAIN_TABELLEN), også når arbeidsområdet eller kontoen slettes og i den nattlige kjøringen for foreldreløse data; de har ingen egen lagringstid. De inneholder skriptadresser, sideadresser og, ved godkjenninger, den godkjennende personen og en begrunnelse i fritekst.	Gjelder prinsippet om lagringsbegrensning (art. 5(1)(e)); endringsloggen med godkjenningene fortsetter å vokse så lenge domenet finnes.
Abonnenter i tilbakekalte portaler	En tilbakekalt portal sperres, slettes ikke; abonnentene beholdes frem til arbeidsområdet slettes.	Formålet (sending av rapporten) opphørte ved tilbakekallingen.
Studielister uten lagringstid	Etter publisering beholdes verter og segmenter; studier som aldri publiseres, beholder også rådataene.	Løftet «rådata slettes» gjelder bare publiserte studier.
Interne kontroller uten slettevei	Kontroller med tillitsnivået «internal» som verken har domene eller rapport (studier og kontroller opprettet av operatøren fra kommandolinjen), omfattes ikke av noen slettevei; sammen med dem beholdes skjemaer, funn og skjermbilder av tredjepartsnettsteder.	Gjelder prinsippet om lagringsbegrensning (art. 5(1)(e)); berører personer som ikke vet noe om kontrollen. Vurdert som høy risiko i Vurdering av personvernkonsekvenser.
Dokumentasjon på kontroll fornyes ikke	Dokumentasjon på kontroll kontrolleres én gang; det finnes ingen vei i koden der et domene mister den igjen.	Aktive testinnsendinger, filsøk og skanning bak innlogging fortsetter etter bytte av eier eller oppdrag.
Skanning bak innlogging: transport til Kundens side	Som innloggingsadresse tillates http i tillegg til https, og sertifikatfeil på Kundens side stopper ikke innloggingen.	Testkontoens innloggingsopplysninger kan fanges opp på vei til Kundens side.
Sletting avhenger av et tidsvindu	Den daglige blokken kjører bare hvis en statuskjøring starter mellom 03:00 og 03:04. Hvis denne ene kjøringen mislykkes (database utilgjengelig, server startet på nytt), skjer ikke dagens sletting og sikkerhetskopiering; ingen etterkjøring finnes. Det som ble slettet, logges ikke varig.	Lagringstidene forlenges da ubemerket med én dag. Et tapt vindu utløser intet varsel; bare en sikkerhetskopiering som kjører og mislykkes, rapporteres. Oppsettslisten i administrasjonsområdet viser datoen for siste vellykkede sikkerhetskopi.
Noen slettinger avhenger av overvåking	Tømming av leveringskontrollens kontrollpostkasse, sletting av hendelser, sendte sammendragsvarslinger, svermsignaler og kontroller av potensielle kunder, og fjerning av gjenværende testkontokopier i jobber kjører i planleggerdelen av statuskjøringen, som bare virker mens overvåking er slått på i administrasjonsområdet; tilordningene i leveringskontrollen slettes bare mens en kontrollpostkasse er satt opp.	Hvis overvåking slås av sentralt eller postkassen fjernes, stopper disse lagringstidene uten at noen merker det.
Rapporteringspunkt og postkasser uten lagringstid	Sårbarhetsrapporter og andre innkommende e-poster oppbevares utenfor applikasjonen; ingen lagringstid er fastsatt.	Rapporter kan inneholde tredjepartsdokumentasjon.
Verdier i skjulte felt leses under kontrollen	Skanneren leser verdien i skjulte skjemafelt inntil 24 tegn og dataattributter inntil 60 tegn for å gjenkjenne tidsstempler og tokener. Bare feltnavn, type, etikett og gjenkjenningsresultatet går inn i feltkartet og funnene, ikke verdien.	Ingen lagringsmangel; verdien finnes bare i arbeidsminnet til skannecontaineren under kontrollen. En forhåndsutfylt verdi (som et kundenummer) leses i prosessen, men lagres ikke.
Utledet avsenderdomene i autentiseringsresultatet	A.1.	For besøkendes personlige domener personopplysninger som stammer fra en reell melding.
Herding av serveradministrasjonen ikke fullført; interne tilkoblinger ikke gjennomgående kryptert	Punkt 8.1. Herdingen fortsetter; vi oppgir ikke detaljer offentlig.	En sikkerhetshendelse på servernivå ville ramme applikasjon, database og sikkerhetskopier samtidig.
Måling på utviklingssystemet	Skjema, kode og innstillinger ble målt på utviklingssystemet.	Kode og skjema samsvarer med produksjonssystemet; innstillinger kan avvike og må kontrolleres på nytt der før lansering.

11. Vedlikehold av denne protokollen

Art. 30 krever at protokollen føres skriftlig og stilles til rådighet for tilsynsmyndigheten på forespørsel. Det krever en ansvarlig person og et intervall der den kontrolleres mot systemet i stedet for mot sin forrige versjon.

• Ansvar: Lukas Wójcik, eier. Den gjennomgås årlig og hver gang en behandlingsaktivitet endres.
• Hendelser som krever oppdatering: En ny eller endret underdatabehandler, særlig valget av e-postleverandør; en ny tabell eller et nytt felt med personopplysninger; en endring i lagringstidene eller slettekjedene i cfg/fristen_lib.php eller srv/cron_status.php; en ny varslingskanal eller en ny forespørsel til tredjepart; aktivering av en funksjon som er av som standard (svermbeskyttelse med IP-nettverk, uavhengig kontrollinstans, egne domener, partnerprogram, betaling mot faktura, Spamhaus eller Google Web Risk); flytting til andre servere.
• Fremgangsmåte: Hvert utsagn her kommer fra kode, skjema eller måling. En gjennomgang som bare leser teksten, har ikke gjennomgått noe: Skjema og slettekjeder måles på nytt, plassholdere forblir plassholdere, åpne spørsmål lukkes eller videreføres med begrunnelse.
• Forholdet til andre dokumenter: Denne protokollen erstatter ikke Personvernerklæringen, Databehandleravtalen, Tekniske og organisatoriske tiltak eller listen over underdatabehandlere. Der de og denne protokollen avviker, er forskjellen et funn.
• Endringer i dette dokumentet oppføres på siden Endringer i avtaledokumentene.