Det här dokumentet publiceras på flera språk. Vid avvikelser mellan språkversionerna är den polska versionen bindande.
Version 1.2 · Senast uppdaterad: 29 oktober 2026
1. Så läser du detta register
Detta är registret över behandling enligt Art. 30 GDPR för formexposed. Det är ingen integritetspolicy och ingen marknadsföring. Dess uppgift är att visa en tillsynsmyndighet, en kund som granskar oss som personuppgiftsbiträde, eller nästa person som måste besvara en fråga, vad som faktiskt behandlas, var det finns, vem som tar emot det och hur länge det sparas. Vi publicerar det eftersom en tjänst som kontrollerar och övervakar formulär själv bör kunna kontrolleras.
Tre regler styrde hur det skrevs.
- Uppmätt, inte avsett. Ett påstående om datafält, lagringstider, mottagare eller skyddsåtgärder förekommer endast där programkoden, databasschemat eller en mätning stöder det. Det som är planerat kallas ”planerat”. Det som är avstängt som standard kallas ”avstängt som standard”. Där vi inte kan bevisa något säger vi det.
- Lagringstiden anges två gånger. En gång för varje behandling och en gång i avsnitt 6 som helhetsbild: vilken nattlig körning som raderar vilka uppgifter, och vilka uppgifter den inte når. Ett register som anger en lagringstid som bara gäller för en del av uppgifterna är sämre än ett som nämner den öppna punkten.
- Öppna punkter anges i texten, inte i en fotnot. Avsnitt 8.1 listar åtgärder som ännu inte har genomförts, avsnitt 10 de öppna punkterna med de planerade åtgärderna. Ett register är ett arbetsverktyg, inte ett certifikat.
Datafält i stället för tabellnamn. För varje behandling listar vi de lagrade uppgifterna som fält i klartext. Namnet på databastabellen följer inom parentes så att en granskare kan hitta stället, till exempel ”inloggningsförsök (login_attempts)”. Fältlistorna har härletts ur databasschemat, inte ur minnet.
Lagringstider som platshållare. Där en lagringstid kan ställas in i administrationsområdet anges den här exakt så som den nattliga körningen läser den: siffran du ser kommer från samma inställning som styr raderingen. Lagringstider som är fastlagda i programmet anges som siffror.
Mätunderlag. Schema, kod och inställningar mättes den 11 oktober 2026 på utvecklingssystemet, som motsvarar produktionssystemet i kod och schema. Vi anger inga radantal från utvecklingssystemet; de innehåller testdata och säger ingenting om den verkliga driften.
Medvetet utelämnat. Detta register nämner inte värdnamn, interna nätverksadresser, portar, användarnamn eller programvaruversioner för våra servrar. Sådana uppgifter hjälper en angripare och ingen registrerad. Av samma skäl beskriver vi öppna punkter i säkringen av våra egna servrar endast i allmänna ordalag (avsnitt 8.1): vi nämner risken, inte vägen dit. Vi lämnar detaljerna till en tillsynsmyndighet på begäran.
Rättslig karaktär. Detta register är den dokumentation vi för enligt Art. 30 GDPR för tillsynsmyndigheten; det publiceras frivilligt. Det utgör inte en del av något avtal och utgör ingen utfästelse, garanti eller överenskommelse om kvalitet gentemot kunder eller tredje parter. Vad vi är skyldiga kunderna regleras av användarvillkoren, personuppgiftsbiträdesavtalet och dess bilagor; när det gäller dessa skyldigheter har de företräde framför detta register. Registret beskriver läget per datumet för denna version. Klassificeringar som ”öppen punkt” eller ”bedömning” återspeglar vår egen uppfattning och föregriper inte någon rättslig bedömning av en tillsynsmyndighet eller en domstol; åtgärder som beskrivs som ”planerade” är avsikter utan bindande datum.
2. Den juridiska personen och varför detta register har två halvor
| Fält | Uppgift |
| Juridisk person | LW IT Solutions Company Lukas Wójcik, enskild firma registrerad i det polska näringsregistret (CEIDG); ägare Lukas Wójcik |
| Adress | al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen |
| Skatteidentifierare | NIP 7252266190, momsregistreringsnummer PL7252266190 |
| Kontakt | contact@lukaswojcik.com; supportfönstret (frågetecknet i navigeringen); kontaktsidan |
| Tjänst | formexposed: kontroll, övervakning och säkring av kontaktformulär på webbplatser (app på formexposed.com, landningssida på form.exposed) |
| Företrädare enligt Art. 27 GDPR | Ej tillämpligt. Den juridiska personen är etablerad i unionen (Polen). |
| Dataskyddsombud | Inte utsett. Bedömningen enligt Art. 37 finns i avsnitt 9. |
| Behörig tillsynsmyndighet | Prezes Urzędu Ochrony Danych Osobowych (UODO, den polska dataskyddsmyndigheten), ul. Moniuszki 1A, 00-014 Warszawa |
| Drift | Våra egna servrar i Polen: en webbserver med applikationen och databasen, och en skanningsserver med en lokal språkmodell i samma interna nätverk. Inget datacenter eller molnleverantör från tredje part. |
formexposed spelar olika roller gentemot olika grupper av personer. Att blanda ihop dem ger ett register som inte stämmer för någon av dem.
- Personuppgiftsansvarig (del B, Art. 30(1)). Vi är själva personuppgiftsansvariga för uppgifterna om våra egna kunder och deras teammedlemmar (konto, inloggning, fakturering, support, loggar), för besökare på vår egen webbplats, för kontroller utan konto (kostnadsfri kontroll, headerverktyg, studie, kontroll av potentiella kunder) och för förebyggande av missbruk.
- Personuppgiftsbiträde (del A, Art. 30(2)). För personuppgifter om tredje parter som en kund för in i tjänsten eller som uppstår när vi utför en tjänst för kunden agerar vi för kundens räkning: kopior av verkliga formulärmejl i leveranskontrollen, prenumeranter på kundens klientportal, mottagare av kundens larm, personer som råkar synas på kundens kontrollerade sidor, inloggningsuppgifterna till kundens testkonto och den formulärkod som kunden klistrar in. Grunden är personuppgiftsbiträdesavtalet, som ingås med varje kund vid registreringen.
- Endast på kundens sida. Vissa funktioner i WordPress-pluginet och TYPO3-tillägget behandlar uppgifter uteslutande på kundens webbplats, utan att uppgifterna någonsin når oss (karantän, skyddsnät, räknepussel, lagringsinställningar, lokala räknare, inspelare). De utgör inte behandling av oss och förekommer därför i ingen av delarna. Vi beskriver dem ändå i slutet av del A så att gränsen syns.
Uppdelningen är inbyggd i koden, inte bara i texten: från ett verkligt formulärmejl skriver leveranskontrollen endast tidpunkten, kopplingen och autentiseringsresultatet i databasen; skärmbilderna från webbläsarkontrollerna maskerar inmatningsfält; testkontots inloggningsuppgifter krypteras så att webbservern inte längre kan läsa dem. Detaljerna anges i posterna.
Avsnitten 6 till 11 gäller för båda halvorna: lagring, automatiserade beslut, tekniska och organisatoriska åtgärder, dataskyddsombud, öppna punkter och underhållet av detta register.
Omfattning. Detta dokument är den del av registret som gäller tjänsten formexposed. Behandling som samma juridiska person utför för andra tjänster förs i deras egna register; allmän bokföring och företagsadministration utanför tjänsten omfattas inte av denna del.
3. Del A – Art. 30(2): behandling för kunders räkning
A.0 Inblandade parter
| Fält | Uppgift |
| Personuppgiftsbiträde | LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen; contact@lukaswojcik.com |
| Personuppgiftsansvariga | Kunderna till formexposed: företag och byråer som har domäner i sitt konto och använder funktioner där uppgifter om tredje parter uppstår. När det gäller byråer kan byråns egen klient dessutom vara personuppgiftsansvarig; byrån agerar då som personuppgiftsbiträde gentemot klienten och vi som ytterligare personuppgiftsbiträde. |
| Förteckning över personuppgiftsansvariga | Del av detta register, förd i elektronisk form (Art. 30(3) GDPR) i tjänstens system och inte återgiven i denna offentliga version, eftersom den innehåller personuppgifter om kunder och skulle vara inaktuell med varje ny kund: ägaren till varje arbetsyta med namn, e-postadress och företag från kundkontot (adress och momsregistreringsnummer endast hos Stripe) (users, workspaces, workspace_users), plus arbetsytans domäner (domains). Vi lämnar den till en tillsynsmyndighet som utdrag på begäran. |
| De personuppgiftsansvarigas företrädare och dataskyddsombud | Det finns inget särskilt fält för detta i systemet. Om en kund har utsett en företrädare enligt Art. 27 GDPR eller ett dataskyddsombud kan kunden meddela oss detta; vi förvarar meddelandet tillsammans med förteckningen över personuppgiftsansvariga. |
| Personuppgiftsbiträdets företrädare | Ej tillämpligt (etablerat i Polen). |
| Dataskyddsombud | Inte utsett (avsnitt 9). |
| Instruktioner | Instruktionen följer av personuppgiftsbiträdesavtalet och av de inställningar som kunden gör: kunden aktiverar leveranskontrollen, konfigurerar larmmottagare, sparar ett testkonto och konfigurerar en klientportal. Utan den åtgärden sker inte den aktuella behandlingen. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8 och sidan Tekniska och organisatoriska åtgärder gäller för varje behandling i del A. Särskilda åtgärder anges i respektive post. |
A.1 Leveranskontroll – kontrollkopia av formulärmejl
| Fält | Uppgift |
| Ändamål | Kontroll av om mejlet från kundens kontaktformulär faktiskt skickas och hur det autentiseras (SPF, DKIM, DMARC, alignment). Efter en godtagen aktiv testinlämning måste dess kopia komma fram till kontrollbrevlådan inom en justerbar väntetid (för närvarande 3 timmar); annars utlöses larmet ”Testmejl inte mottaget”. Rubrikerna används också för att härleda formulärmejlets äkthet, den använda e-posttjänsten och avsändaradressen för blocklistekontrollen. |
| Förutsättning | Betalabonnemang, verifierad domän, aktiverad av kunden. Kunden anger sin egen kontrolladress med en identifierare (i formen ”delivery+identifierare@…”) som dold kopia i formulärets avisering. Utan konfigurerad kontrollbrevlåda är funktionen inte tillgänglig. |
| Kategorier av registrerade | Besökare på kundens webbplats som skickar kundens formulär; personer vars uppgifter en besökare skriver in i meddelandet; kundens personal som förekommer som mottagare i rubrikerna. |
| Kategorier av personuppgifter | I kontrollbrevlådan (hos e-postleverantören): den fullständiga kopian av varje formulärmejl, inklusive verkliga förfrågningar med namn, e-postadress, telefonnummer och fritext, fram till radering. Läst av hämtningen: rubrikerna och högst de första 8 KB av brödtexten. I databasen: tidpunkt för mottagandet, koppling till domänen och i förekommande fall till testkörningen (delivery_log); det senaste autentiseringsresultatet per domän med SPF-, DKIM- och DMARC-resultat, alignment, avsändardomän, signerande domäner och adressen till den sändande e-postservern (autentiseringsfältet för domänen i domains). Innehåll, ämne och besökarens avsändaradress skrivs inte till databasen. |
| Anmärkning om avsändardomänen | Om ett formulär anger besökarens adress som avsändare (en felkonfiguration som kontrollen är utformad för att avslöja) innehåller autentiseringsresultatet domänen för den adressen, inte själva adressen. Om en besökare använder en personlig domän kan även denna vara en personuppgift. Den skrivs över vid nästa mottagande. |
| Källa | Formuläret på kundens webbplats, via den dolda kopia som kunden angett. |
| Rättslig grund (bestäms av den personuppgiftsansvarige) | Bestäms av kunden. Vårt textförslag till kundens integritetspolicy grundar kopian på Art. 6(1)(f) GDPR (berättigat intresse av att tillförlitligt ta emot förfrågningar). Kunden informerar sina besökare om detta dataflöde; personuppgiftsbiträdesavtalet förpliktar kunden att göra det. |
| Mottagare | Den e-postleverantör som driver kontrollbrevlådan (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). Kopian går direkt dit: den kommer endast fram om MX-posterna för vår domän pekar på denna brevlåda (checklistan inför lanseringen kontrollerar detta); via vidarebefordran når den inte brevlådan. På domänsidan ser kunden endast tidpunkt, koppling och autentiseringsresultat. Om autentiseringsresultatet försämras nämner larmet till kunden och till de kanaler kunden har valt avsändardomänen om den inte hör till webbplatsen (A.3, 4.1). |
| Tredjeland | Beror på e-postleverantören; se avsnitt 4. Avtalet med den avsedda leverantören och överföringsgrunden är ännu inte dokumenterade. |
| Lagring | Efter lyckad behandling markeras mejlet för radering och tas bort från brevlådan i samma körning, även om det inte kan kopplas till någon domän. Hämtningen körs med statuskörningen var femte minut medan övervakningen är aktiverad i administrationsområdet (srv/cron_status.php, cfg/zustellung_lib.php). Om hämtning eller radering misslyckas ligger mejlet kvar i brevlådan till nästa lyckade körning. Samma hämtning raderar kopplingarna i delivery_log efter 180 dagar. Autentiseringsresultatet finns kvar lika länge som domänen. |
| Vad beviset visar | Endast mottagandet i kontrollbrevlådan av den kopia som kopplats till den specifika testkörningen. Det bevisar varken mottagande hos den faktiska mottagaren eller en registrering i CRM-systemet. Inbyggd bekräftelse från HubSpot erbjuds inte. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Särskilt: innehållet utvärderas endast i minnet; ingen lagring av brödtext, ämne eller fullständiga avsändaradresser; radering oavsett om kopplingen lyckades. |
Leveranskontrollen är den enda funktion genom vilken verkliga meddelanden från våra kunders besökare når oss. Därför är den behandling för kundens räkning och inte en tjänst under vårt eget ansvar, och därför är tiden i brevlådan det verkliga måttet på risken: normalt minuter; om hämtningen störs, tills den körs igen. Kopior bör inte innehålla särskilda kategorier av personuppgifter; det kan vi inte förhindra tekniskt, eftersom det som en besökare skriver bestäms av besökaren.
A.2 Klientportal och månatlig rapport till prenumeranter
| Fält | Uppgift |
| Ändamål | En byrå (Business-abonnemang) visar sina klienter tillståndet för deras domäner under eget varumärke (portal på en slumpmässig adress, valfritt med lösenord, valfritt under en underdomän till byråns egen domän). Klienten kan där beställa en månatlig rapport via e-post. Rapporten skickas i byråns namn. |
| Kategorier av registrerade | Byråns klienter och deras personal som beställer rapporten; personer som öppnar portalen. |
| Kategorier av personuppgifter | Prenumerant: e-postadress, språk, bekräftelseidentifierare, tidpunkt för beställningen och IP-adress vid beställningen, tidpunkt för bekräftelsen (dubbel opt-in), tidpunkt för avregistrering, senast skickade månad (client_subscribers). Portal: namn, urval av domäner, slumpmässig identifierare, lösenord endast som hash, person som skapade den, tidpunkt, återkallelse (client_portals). Besök i portalen förekommer i loggen över sidvisningar (B.2). |
| Källa | Angivet av prenumeranterna själva i portalen. |
| Rättslig grund (bestäms av den personuppgiftsansvarige) | Prenumerantens samtycke, inhämtat genom ett förfarande med dubbel opt-in; personuppgiftsansvarig är byrån. Vi skriver inte till någon som inte själv har anmält sig och bekräftat. |
| Mottagare | Byrån (ser sina prenumeranter); e-postleverantören (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) för bekräftelsemejlet och rapporten. |
| Tredjeland | Via e-postleverantören; se avsnitt 4. |
| Lagring | Nattlig raderingskörning (cfg/fristen_lib.php, delen ”portalprenumeranter”): beställningar som aldrig bekräftats efter 30 dagar; avregistrerade prenumeranter tre år efter avregistreringen, som bevis på det tidigare samtycket. Bekräftade prenumeranter som inte har avregistrerat sig finns kvar så länge byråns arbetsyta finns. En återkallad portal blockeras endast, raderas inte; dess prenumeranter får inte längre rapporter, men deras uppgifter finns kvar (avsnitt 10). Portaler och prenumeranter försvinner omedelbart med arbetsytan (fe_arbeitsbereich_daten_loeschen()). Skickade rapporter ligger kvar i utkorgen i 30 dagar (B.25). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Särskilt: portallösenord endast som hash, gissningsförsök begränsade (tio per portal och IP-adress, 50 per portal på 15 minuter); avregistrering med ett klick i varje mejl; portalen visar endast status och nyckeltal, inga enskilda resultat med bevis. |
A.3 Kundens larmmottagare, kvitterare och ansvariga
| Fält | Uppgift |
| Ändamål | Aviseringar om fel och ändringar till de mottagare som kunden konfigurerar för en domän: e-post, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Per mottagare omedelbart, eller samlat dagligen eller veckovis, plus mottagare enbart för eskaleringar. Varje problemavisering blir en incident som mottagaren kan kvittera via en länk. För övervakade formulär kan kunden ange en ansvarig person och ett förfallodatum. |
| Kategorier av registrerade | Kundens personal och tjänsteleverantörer som kunden anger som larmmottagare eller utser som ansvariga; personer som kvitterar en incident. Teammedlemmar med eget konto förekommer även i del B. |
| Kategorier av personuppgifter | Larmmottagare: kanal, mottagaradress (e-postadress, webhook- eller chattadress, Telegram-chatt-ID), valda händelser, leveranssätt, signeringshemlighet för webhooks, senaste leverans och senaste fel (alerts). Leveranslogg: mottagare, händelser, status, fel, tidpunkt (alert_log). Kö för sammanfattningar: aviseringsrader och länk fram till leverans (alert_queue). Incident: titel, aviseringsrader, länk, kvitteringsidentifierare, tidpunkt och namn eller e-postadress för den person som kvitterar så som det angetts i formuläret, annars adressen till den inloggade medlemmen (alert_incidents). Leveransförsök vid eskalering per incident och mottagare: antal försök (högst fem), tidpunkter för det senaste och nästa försöket och för lyckad leverans, hänvisning till mejlet i utkorgen, fel (tabellen alert_escalation_deliveries). Tilldelning: den ansvariga personens konto och förfallodatum (i monitored_forms). |
| Aviseringarnas innehåll | Domän, händelse, en kort förklaring och en länk till domänsidan. Inget innehåll från besökares meddelanden. |
| Källa | Angivet av kunden; den kvitterande personen anger själv sitt namn; Telegram-chatt-ID:t skapas när mottagaren trycker på ”Start” i boten (B.32). |
| Rättslig grund (bestäms av den personuppgiftsansvarige) | Bestäms av kunden; som regel organisationen av kundens egen verksamhet (Art. 6(1)(b) eller (f) GDPR i förhållande till kundens personal och tjänsteleverantörer). |
| Mottagare | Operatörerna av de valda kanalerna; se 4.1. Larm via e-post via e-postleverantören (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tredjeland | Beroende på vald kanal; flera leverantörer har sitt säte i USA, Telegram utanför EU utan beslut om adekvat skyddsnivå. Se 4.1. |
| Lagring | Leveransloggen efter 90 dagar (nattligen, fe_alert_log_aufraeumen() från srv/cron_status.php). Sammanfattningsaviseringar 30 dagar efter leverans (cfg/kanal_lib.php, vid varje leverans av sammanfattning). Incidenter så länge de är olösta; lösta 180 dagar efter lösning (cfg/vorfall_lib.php, eskaleringskörning), tillsammans med deras leveransförsök vid eskalering. Larmmottagare och tilldelningar tills kunden raderar dem eller tillsammans med domänen. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Särskilt: webhooks signerade med en separat hemlighet per mottagare; kvittering först efter ett klick (POST), så att länkförhandsvisningar i chattprogram inte utlöser något; larm under ett underhållsfönster loggas endast, skickas inte. |
A.4 Personer som råkar synas på kontrollerade kundsidor och i skärmbilder
| Fält | Uppgift |
| Ändamål | Kontrollen av domänerna i kundens konto (skanning, övervakning, aktiv kontroll) läser kundens offentliga sidor och tar skärmbilder av formulär. Det som sidan själv visar kan gälla personer som inte har något med kontrollen att göra. Dessa uppgifter uppstår i förbigående; de är inte kontrollens syfte. |
| Kategorier av registrerade | Personer vars namn, foto eller kontaktuppgifter förekommer på den kontrollerade sidan (kontaktperson bredvid formuläret, teamfoton på startsidan, uppgifter i företagsinformationen). |
| Kategorier av personuppgifter | Skärmbilder: det synliga området av startsidan, varje synligt formulär som utsnitt och bilden av uppföljningssidan efter en aktiv testinlämning; lagrade som filer utanför webbkatalogen, med endast hänvisningen i databasen (scan_screenshots). Formulärstruktur: sidadress, selektor, fältnamn, fälttyper, fältetiketter, flaggor för obligatoriska fält och synlighet, etiketter på skicka-knappar (forms, fältet ”field map”); inga fältvärden. Skannern läser början av dolda fält (upp till 24 tecken) och dataattribut (upp till 60 tecken) endast under kontrollen, för att känna igen tidsstämplar och tokens; endast resultatet sparas. Resultat med bevis (findings), sammanfattning med sidtitlar (scans). Om en e-postadress förekommer i formuläret som mottagare sparas endast dess domän, aldrig adressen. |
| Källa | De offentliga sidorna på kundens domän, hämtade av skannern. |
| Rättslig grund (bestäms av den personuppgiftsansvarige) | Bestäms av kunden för innehållet på kundens egen webbplats. För oss är behandlingen en del av den beställda kontrollen. |
| Mottagare | Kunden; när det gäller byråer deras klient via portalen eller en white label-rapport; alla som får en rapportlänk (rapporter på slumpmässiga adresser, inte i sökmotorer). Där formulärtypen är oklar får en lokal språkmodell på vår egen server formulärstrukturen med sidtitel, sidadress och formulärets synliga text (upp till 400 tecken) för klassificering; den får inga bilder. |
| Tredjeland | Inget. |
| Lagring | Kontrollresultat för en domän i högst 13 månader; den senaste slutförda kontrollen per domän finns kvar (nattlig raderingskörning, delen ”gamla kontrollresultat”). Formulär, resultat, bildhänvisningar och bildfilerna försvinner med kontrollresultatet. Med domänen försvinner dessa uppgifter omedelbart (raderingskedja i B.15; undantag i avsnitt 6.4). |
| Maskeringens gränser | Skärmbilderna från den fullständiga kontrollen maskerar ingenting: de visar det som sidan visar för varje besökare. Formulärfält är tomma vid hämtningen, eftersom skannern inte fyller i något; förifyllda värden skulle synas. Inga skärmbilder tas bakom en inloggning (A.5). Bilderna från webbläsarkontrollerna maskerar inmatningsfält (A.6). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Särskilt: bilder kan endast hämtas via rapporten, och någon annans bildidentifierare ger ”hittades inte”; rapporter med noindex; varje kontroll körs i en egen isolerad container. |
Samma uppgifter uppstår vid kontroller utan konto (kostnadsfri kontroll, studie, kontroll av potentiella kunder). Där finns ingen kund för vars räkning vi agerar; dessa fall förekommer därför i del B (B.5, B.7, B.8).
A.5 Testkontots inloggningsuppgifter för skanningen bakom inloggningen
| Fält | Uppgift |
| Ändamål | Läsning av formulär som visas först efter inloggning (kundområde, medlemsområde). Skannern loggar in med ett testkonto som kunden har skapat på sin egen webbplats och läser de angivna sidorna. Utöver inloggningsformuläret skickar den ingenting, utför inget aktivt test där, tar inga skärmbilder och besöker inte adresser för utloggning, radering eller uppsägning. Om inloggningsformuläret har en CAPTCHA avbryter den; CAPTCHA kringgås inte. |
| Förutsättning | Verifierad domän, betalabonnemang, rollen ägare eller administratör, uttrycklig bekräftelse på att kontot är ett testkonto. Högst fem sidor, alla på samma domän. |
| Kategorier av registrerade | Den person i vars namn testkontot innehas (helst ingen; kunden bör använda ett funktionskonto); personer vars uppgifter förekommer på sidorna bakom inloggningen. |
| Kategorier av personuppgifter | Testkontots användarnamn och lösenord, endast krypterade; en ledtråd till användarnamnet (första tecknet och längden); inloggningsadress, lista över sidor, namn på inloggningsfälten, indikator för lyckad inloggning, person som skapade den, tidpunkter, senaste resultat som kortkod (domain_logins). För ett pågående jobb en kopia av chiffertexten (fältet ”login package” i scan_jobs). Från sidorna bakom inloggningen: formulärstruktur som i A.4, utan skärmbilder och utan cookies. |
| Källa | Angivet av kunden i kontot. |
| Rättslig grund (bestäms av den personuppgiftsansvarige) | Bestäms av kunden. Kunden garanterar att kunden har rätt att använda testkontot. |
| Mottagare | Inga. Varken kunden, supporten eller programmeringsgränssnittet kan läsa ut inloggningsuppgifterna; gränssnittet visar endast ledtråden till användarnamnet. |
| Tredjeland | Inget. |
| Skydd av inloggningsuppgifterna | Användarnamn och lösenord krypteras omedelbart vid lagringen med skanningsserverns offentliga nyckel (X25519, HKDF-SHA256, AES-256-GCM; domänen binds som associerade data, så att en chiffertext inte kan kopplas till en annan domän). Endast skanningsservern har den privata nyckeln. Webbserver, databas och säkerhetskopior innehåller endast chiffertext; inte heller vi kan dekryptera den där. Skanningsservern dekrypterar endast för körningen, lämnar inloggningsuppgifterna till den isolerade kontrollcontainern endast via standardinmatning, raderar kopian i jobbet omedelbart och skriver den inte i något resultat, någon logg eller feltext. På vägen till kundens webbplats skyddas de endast av den webbplatsens kryptering; gränserna för denna transport anges i avsnitt 10. |
| Lagring | Sparade inloggningsuppgifter tills kunden raderar dem. Vid radering skrivs chiffertexten över med slumpmässiga data av samma längd och raden raderas; väntande jobb rensas (fe_login_loeschen()). Med domänen försvinner raden via en främmande nyckel. Skanningsservern rensar kopior i jobb efter körningen; det som finns kvar (jobbet avbrutet, skanningsservern nere) rensas av statuskörningen senast efter en timme (fe_login_aufraeumen(), delen ”login_jobs”). Databasens säkerhetskopior innehåller chiffertexten tills säkerhetskopian löper ut efter 14 dagar. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Särskilt: asymmetrisk kryptering med separata nycklar; spärrlista för utloggnings- och raderingssökvägar; inga skärmbilder bakom inloggningen; funktionen endast för betalabonnemang och verifierade domäner; varje ändring i aktivitetsloggen (utan inloggningsuppgifter). |
Vi har medvetet inte byggt något sätt att spara inloggningsuppgifter till kundens server, CMS-administrationsområde eller webbhotellskonton. Testkontot är ett besökarkonto på kundens webbplats, inte en åtkomst till kundens system.
A.6 Konfigurerade formulärflöden, webbläsarkontroller och oberoende sond
| Fält | Uppgift |
| Ändamål | Ett övervakat formulär gås igenom i en riktig webbläsare (Chromium, WebKit eller båda) fram till steget precis före inlämning: ladda sidan, utföra föregående klick (högst fem, aldrig på ett inmatningsfält eller en skicka-knapp), fylla i fält med igenkännbart syntetiska värden (till exempel en adress under den reserverade ändelsen .invalid), gå vidare i formulär med flera steg. Webbläsarkontrollen skickar ingenting; inlämning är tekniskt blockerad i webbläsaren. Dessutom tidsmätningar och visuella jämförelser av formuläret. |
| Kategorier av registrerade | Som A.4 (personer som syns på formulärsidan); kundens personal som angetts som ansvariga (A.3). |
| Kategorier av personuppgifter | Konfiguration: formuläradress, selektorer, ingångsadress, klicksteg, val av webbläsare, etikett, kritikalitet, tilldelning, förfallodatum (monitored_forms). Resultat per körning: tillstånd, teknisk felorsak, rensade felmeddelanden, nätverks- och tidsmätningar, en bild av formuläret som JPEG på högst 32 KB med maskerade inmatningsfält (form_browser_runs). Observationer per kontroll (form_observations), tidsserier (form_performance). Jobb med mållista (fälten ”targets” och ”result” i scan_jobs). |
| Teståtkomst | Om kunden har sparat ett testkonto (A.5) använder den fullständiga kontrollen det även för konfigurerade formulärflöden. Enligt den uppmätta koden fungerar de fristående webbläsarkontrollerna mellan två fullständiga kontroller utan testkonto. |
| Oberoende sond | En andra kontrollpunkt på en annan plats är förutsedd, som skulle göra en motkontroll före ett larm. Den skulle få domänen, den rensade konfigurationen och jobbidentifieraren, inga besökarinmatningar och inga inloggningsuppgifter. Den är för närvarande inte konfigurerad (avstängd som standard). Utan sonden finns inget bevis från en andra plats; ett larm grundar sig då på vår egen mätning. |
| Källa | Konfigurerat av kunden; resultat från hämtningen av kundens sida. |
| Rättslig grund (bestäms av den personuppgiftsansvarige) | Bestäms av kunden för innehållet på kundens webbplats och för ansvarsfördelningen bland kundens personal. |
| Mottagare | Kunden; om en sond är konfigurerad, dess operatör (för närvarande ingen). |
| Tredjeland | Inget. |
| Lagring | Resultat från webbläsarkörningar, slutförda webbläsarjobb och tidsserier efter 13 månader (nattlig raderingskörning, delarna ”browser_runs”, ”browser_jobs”, ”form_performance”). Konfigurationer tills domänen raderas (de kan ändras eller stängas av var för sig, inte raderas); med domänen försvinner de, tillsammans med körningar, observationer och tidsserier, via främmande nycklar. |
| Vad mätningen visar | Tider och tillstånd från vår kontrollwebbläsare. De mäter inte vad verkliga besökare upplever och bevisar varken slutförandegrader eller förlorade förfrågningar. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Särskilt: inlämning tekniskt förhindrad; endast adresser på samma domän; maskerade bilder; isolerad kontrollcontainer. |
A.7 ”Fix it for me” – inklistrad formulärkod
| Fält | Uppgift |
| Ändamål | Kunden klistrar in koden för sitt formulär; en språkmodell på vår egen hårdvara bygger in skyddsmodulen. Det som returneras är den ändrade filen, en patch, resultatet av en syntaxkontroll och en indikation på om kontrollanropet faktiskt har byggts in. Utan inklistrad kod levererar tjänsten en färdig modul med fältnamnen från den senaste skanningen. |
| Kategorier av registrerade | Personer vars uppgifter råkar finnas i den inklistrade koden (till exempel en mottagaradress, namn i kommentarer, inloggningsuppgifter till en e-postserver). |
| Kategorier av personuppgifter | Den inklistrade koden, högst 30 000 tecken. I databasen endast en post i aktivitetsloggen (åtgärden ”fix_ai” med arbetsyta och tidpunkt), som räknas mot den dagliga gränsen på för närvarande tio anrop per arbetsyta. |
| Källa | Inklistrat av kunden. |
| Rättslig grund | Fullgörande av avtalet med kunden (Art. 6(1)(b) GDPR) för själva koden; för uppgifter om tredje parter som råkar finnas i den bestämmer kunden grunden. |
| Mottagare | Inga. Språkmodellen körs på vår egen skanningsserver i det interna nätverket; ingen extern AI-tjänst, inte ens som reserv. |
| Tredjeland | Inget. |
| Lagring | Koden sparas inte. En temporär fil skapas för syntaxkontrollen och raderas omedelbart därefter. Posten i aktivitetsloggen raderas efter 365 dagar. |
| Anvisning till kunden | Kod som innehåller lösenord, API-nycklar eller personuppgifter bör rensas innan den klistras in. Vi kontrollerar inte innehållet. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Särskilt: endast ägare och administratörer med betalabonnemang; den inklistrade koden lämnas till modellen märkt som data och körs aldrig; ingen uppladdning till tredje parters servrar. |
A.8 White label-varumärke och byråns kontaktpersoner
| Fält | Uppgift |
| Ändamål | En byrås (Business-abonnemang) rapporter, kortrapporter, bevisloggar och klientportal visas under dess varumärke, på begäran under en underdomän till byråns egen domän. |
| Kategorier av registrerade | Kontaktpersoner hos byrån vars namn eller kontaktuppgifter förekommer i kontaktraden. |
| Kategorier av personuppgifter | Företagsnamn, webbplats, kontaktrad, anteckning till klienten, accentfärg, utseende, logotypfil, reglage för hänvisningen till formexposed, egen domän med verifieringsidentifierare och verifieringsstatus (workspace_branding). |
| Källa | Angivet av byrån. |
| Rättslig grund | Fullgörande av avtalet med byrån (Art. 6(1)(b) GDPR). Där kontaktraden nämner byråns personal bestämmer byrån grunden. |
| Mottagare | Alla som byrån ger en rapport, kortrapport eller portallänk. |
| Tredjeland | Inget. |
| Lagring | Tills byrån ändrar uppgifterna; varumärke och logotypfil försvinner med arbetsytan (fe_arbeitsbereich_daten_loeschen()). En egen domän vars DNS-verifiering misslyckas i sju dagar stängs av. Den egna domänen är avstängd som standard. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
A.9 Räkningar, statusindikatorer och fältfel från pluginet och tillägget
| Fält | Uppgift |
| Ändamål | En gång om dagen rapporterar WordPress-pluginet och TYPO3-tillägget siffror om formulären på den anslutna webbplatsen: blockerade inlämningar per orsak, inlämningar, skickade och misslyckade mejl, statusindikatorer för formulärinställningarna, sparade förfrågningar per källa och lagringstid. Valfritt, avstängt som standard: formulärhändelser och fältfelskategorier per fältposition. Dessa siffror ger ”Skydd i siffror”, månadsrapporten, tystnadslarmet och anvisningar om riskabla inställningar. |
| Klassificering | Siffrorna är utformade så att de inte beskriver någon person. Vi listar dem i del A eftersom de uppstår ur händelser på kundens webbplats som utlöses av kundens besökare; enligt vår uppfattning är de personuppgifter högst i gränsfall (en webbplats med mycket få inlämningar en viss dag). Själva överföringen (nycklar, versioner, värd) finns i del B (B.20). |
| Kategorier av registrerade | Besökare på kundens webbplats som skickar ett formulär. |
| Kategorier av personuppgifter | Dagliga siffror per värd: blockerade totalt och per orsak, inlämningar, skickade och misslyckade mejl, felkategori för e-postutskick (endast en av fyra kategorier, aldrig feltexten, eftersom den kan innehålla mottagaradresser), antal reCAPTCHA-svar, raderade och frisläppta förfrågningar (plugin_stats). Status: versioner från en fast lista över formulär-, CAPTCHA- och e-postplugin, inställningsindikatorer som siffror, lagringstider (plugin_health). Ändringsmeddelanden: namn och version för ett uppdaterat plugin (plugin_changes). Valfritt: räknare per formulär och dag med felkategorier per fältposition (form_metrics). Aldrig: inmatningar, fältnamn, lösenord, filer, e-postadresser, namn, IP-adresser eller beständiga identifierare för besökare. |
| Källa | Pluginet på kundens webbplats, via ett programmeringsgränssnitt med webbplatsens anslutningshemlighet. |
| Rättslig grund (bestäms av den personuppgiftsansvarige) | Bestäms av kunden; kunden avgör om de valfria räkningarna ska aktiveras och hur besökarna ska informeras. |
| Mottagare | Kunden. Domäner från länkar i blockerade meddelanden går in i svärmskyddet (B.21). |
| Tredjeland | Inget. |
| Lagring | Dagliga siffror, ändringsmeddelanden och formulärräknare efter 13 månader (nattlig raderingskörning, delarna ”plugin_stats” och ”form_metrics”). Statusindikatorer skrivs över vid varje rapport. Alla pluginuppgifter för en värd försvinner så snart ingen domän i systemet längre hänvisar till den värden (omedelbart vid radering av den sista domänen; äldre uppgifter nattligen, delen ”orphan_hosts”). |
| Vad siffrorna visar | Vad pluginet har räknat. De bevisar varken slutförandegrader eller förlorade förfrågningar. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Särskilt: mottagande endast med webbplatsens bundna nyckelpar; endast kända nycklar och siffror godtas, allt annat kasseras; dagar utanför ett fönster på 14 dagar avvisas. |
A.10 Gräns: vad som stannar enbart på kundens webbplats
Följande funktioner i WordPress-pluginet och TYPO3-tillägget behandlar uppgifter uteslutande på kundens server. De når inte oss, och vi har ingen åtkomst till dem. Ansvarig är enbart webbplatsens operatör; operatören beslutar om aktivering, lagringstider och hur besökarna informeras. För detta föreslår pluginet stycken till operatörens integritetspolicy.
| Funktion | Vad som behandlas lokalt | Lagring på kundens sida |
| Karantän | Stoppade inlämningar med orsak, kan frisläppas via e-post till webbplatsens adress | 14 dagar |
| Skyddsnät | Inlämningar vars formulärmejl misslyckades, för omsändning (aktiverat som standard) | 30 dagar |
| Räknepussel i stället för reCAPTCHA | Räkneuppgift i besökarens webbläsare, ingen tredjepartstjänst (avstängt som standard) | – |
| Lagringsinställningar | Radering av sparade förfrågningar i formulärplugin efter den period som operatören valt (avstängt som standard) | enligt konfiguration |
| Hastighetsbegränsning | en kortlivad identifierare som härleds från IP-adressen, överförs inte till oss | kortlivad |
| Lokala dagliga räknare | Räknarvärden före överföring | högst 14 dagar |
| Inspelare för administratörer | tekniska selektorer och navigeringssteg i sessionslagringen i en inloggad administratörs webbläsare; inmatningar läses inte. Endast den valda konfigurationen överförs (därefter A.6) | högst 15 minuter |
| Besökarhjälp | kan aktiveras separat; sparar inga utkast och skickar inte om automatiskt | – |
| Observation av nya spamregler | ytterligare träffar räknas lokalt, utan automatisk aktivering | sju dagar |
A.11 Formulärskydd (formconfirmed)
| Fält | Uppgift |
| Ändamål | Bedömning av inskickningar via formulär på kundernas webbplatser för att upptäcka automatiserade inskickningar: utfärdande och kontroll av uppgifter (beräkningsbevis), kontrolltoken för engångsbruk, ifyllnadstid, fällfält, upprepade förfrågningar; på kundens begäran bedömning av meddelandetexten med en språkmodell. Endast för kunder som aktiverar formulärskyddet. |
| Kategorier av registrerade | Besökare på kundernas webbplatser som öppnar en sida med ett skyddat formulär eller skickar in det. |
| Kategorier av personuppgifter | IP-adress (lagras endast förkortad och hashad med en nyckel som byts dagligen), sidans adress och domän, tidpunkter och ifyllnadstid, fällfält ifyllt ja/nej, webbläsaridentifierare i webbserverns logg; endast när innehållskontrollen är aktiverad meddelandetexten (endast i arbetsminnet). |
| Källa | Besökarens webbläsare (uppgift, kontrolltoken); kundens server (kontrollbegäran, i förekommande fall text). |
| Mottagare | Kunden (poäng, åtgärd, skäl). Inga andra; inga underbiträden för denna behandling. |
| Tredjeland | Inget. |
| Lagringstid | Hashad identifierare 1 timme; förbrukade kontrolltoken högst 11 minuter; kontrollresultat utan IP-adress och utan text 30 dagar; dagliga siffror 400 dagar; webbserverns logg 14 dagar; text lagras inte. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8; dessutom förkortning och hashning med dagsnyckel, signerade uppgifter, engångsanvändning, språkmodell på egen hårdvara utan loggning av texten. |
4. Del A – mottagare, underbiträden och överföringar till tredjeland
Följande tabell listar de mottagare som vi själva anlitar och som kan ta emot uppgifter från del A. Den auktoritativa, löpande uppdaterade förteckningen är sidan Underbiträden; om den avviker från denna tabell är det ett fynd, inte en formateringsfråga.
| Mottagare | Vad den tar emot | Tredjeland | Grund | Status |
| Namecheap, Inc. (Private Email), Phoenix, Arizona, USA | Leveranskontrollens kontrollbrevlåda (A.1); utskick av larmmejl (A.3), bekräftelser och rapporter till portalprenumeranter (A.2) | Platsen för behandlingen ska ännu kontrolleras; se sidan ”Underbiträden” | Personuppgiftsbiträdesavtal; överföringsgrunden ska ännu kontrolleras | Öppet. Det relevanta avtalet, de faktiska platserna för behandlingen och överföringsgrunden är ännu inte dokumenterade. Detta register bekräftar varken en certifiering eller ett ingånget avtal. |
| Namecheap, Inc. (registrar, DNS; vidarebefordran av e-post tills brevlådan är konfigurerad) | Tills brevlådan är konfigurerad, allmän inkommande e-post till adresser på vår domän; inte kopiorna från leveranskontrollen, som endast kommer fram med MX-poster som pekar direkt på brevlådan (A.1) | USA | ska kontrolleras: certifiering enligt EU–US Data Privacy Framework eller standardavtalsklausuler | Används; grunden öppen. |
| Vår egen skanningsserver med en lokal språkmodell | Formulärstruktur för klassificering (A.4), inklistrad kod (A.7), dekrypterad teståtkomst endast under körningen (A.5) | – | Drivs av oss, inte en tredje part | Används. |
| Oberoende sond på en andra plats | Domän, rensad konfiguration, jobbidentifierare (A.6) | beroende på plats | ska fastställas före idrifttagning | Inte konfigurerad. |
Drift: ingen tredje part. Applikation, databas, skärmbilder och säkerhetskopior finns på våra egna servrar i Polen. Om vi flyttar till ett datacenter eller en molnleverantör måste detta stycke skrivas om.
4.1 Larmkanaler som kunden väljer
Utöver de mottagare vi anlitar finns det kanaler som kunden väljer för sina larm (A.3). Vår server utlöser överföringen; kunden bestämmer mottagaren och leverantören. Valet av kanal befriar oss inte från våra egna skyldigheter som personuppgiftsbiträde. Roll, avtal och de skyddsåtgärder som krävs för tredjeländer måste fastställas för varje leverantör; för chattjänsterna har detta ännu inte slutförts (öppen fråga för den juridiska granskningen).
| Kanal | Vad som skickas | Leverantörens säte |
| E-post | Domän, händelse, förklaring, länk; till den angivna adressen | via Namecheap, Inc. (Private Email), Phoenix, Arizona, USA |
| Webhook till en fritt vald adress | Händelse som JSON (domän, händelser, rader, länk, tidsstämpel), signerad med mottagarens hemlighet | bestäms av kunden |
| Slack, Discord, Microsoft Teams, Google Chat | samma avisering som chattmeddelande till den angivna webhook-adressen | huvudsakligen USA |
| Telegram | mottagare som kunden valt; vi skickar meddelandet via vår bot till det kopplade chatt-ID:t | utanför EU, inget beslut om adekvat skyddsnivå; överföringsgrunden är en öppen fråga för den juridiska granskningen |
I inget fall skickas innehållet i ett besökarmeddelande. Aviseringarna innehåller domän, händelse och länk.
5. Del B – Art. 30(1): behandling under eget ansvar
Personuppgiftsansvarig för allt i denna del: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, contact@lukaswojcik.com. Ingen företrädare krävs (etablerad i unionen). Inget dataskyddsombud utsett (avsnitt 9). Tekniska och organisatoriska åtgärder: avsnitt 8 och sidan Tekniska och organisatoriska åtgärder. Hur registrerade utövar sina rättigheter beskrivs på sidan Tillgång, radering och dina övriga rättigheter; kontoinnehavare kan själva ladda ned sina uppgifter som en fil (Inställningar).
Där vi stöder oss på berättigade intressen (Art. 6(1)(f) GDPR) anger vi intresset och skälet till att ett mindre ingripande medel inte räcker. Avvägningen är vår bedömning; den ingår i den juridiska granskningen.
B.1 Besökare på vår webbplats – webbserverloggar
| Fält | Uppgift |
| Ändamål | Drift och säkerhet för webbplatsen och appen: leverans, felsökning, upptäckt av attacker och överbelastning. |
| Kategorier av registrerade | Alla som öppnar en sida på formexposed.com eller form.exposed, inklusive besökare på kundsidor vars webbläsare laddar vår märkesbild (B.18), mottagare som öppnar en rapport- eller kvitteringslänk, och webbplatser vars plugin anropar vårt gränssnitt. |
| Kategorier av personuppgifter | Fullständig IP-adress, tidpunkt, begärd adress, statuskod, överförda byte, hänvisande sida (referrer), webbläsaridentifierare (user agent). |
| Var det lagras | Åtkomstloggar från den föregående proxyn och från webbservern som filer på webbservern, inte i databasen. |
| Källa | Den webbläsare eller det program som gör förfrågan. |
| Rättslig grund | Art. 6(1)(f) GDPR. Intresse: säker och oavbruten drift. Avvägning: utan den fullständiga adressen kan upprepade förfrågningar från samma avsändare inte kopplas samman och attacker inte avvärjas; en avkortad adress räcker inte för denna åtskillnad. Loggarna kombineras inte med andra uppgifter och raderas efter kort tid. |
| Mottagare | Inga. |
| Tredjeland | Inget. |
| Lagring | 14 dagar: daglig rotation med 14 generationer, därefter överskrivna (systemets loggrotationstjänst, inte applikationens nattliga raderingskörning). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.2 Applikationens logg över sidvisningar
| Fält | Uppgift |
| Ändamål | Säkerhet och upptäckt av missbruk (vem som begär vad och hur ofta), spårbarhet för kontoåtkomst, enkel användningsstatistik utan analystjänst. |
| Kategorier av registrerade | Alla besökare på webbplatsen och användare av appen vid verkliga sidvisningar (inga bakgrundsförfrågningar, inga formulärinlämningar). |
| Kategorier av personuppgifter | Fullständig IP-adress, det land som härleds från den vid skrivningen (lokal geodatabas, ingen förfrågan till tredje part), konto-ID för inloggade användare, begärd adress och hänvisande sida (åtkomsttokens i dem, till exempel de i rapport- eller portallänkar, maskerade), webbläsaridentifierare och den enhetstyp, det operativsystem och den webbläsare som härleds från den, språk, tidpunkt (access_logs). Under ”Visa som kund” (B.14) sätts inget konto-ID, så att supportens sidvisningar inte visas i kundens logg. |
| Källa | Webbläsarens förfrågan. |
| Rättslig grund | Art. 6(1)(f) GDPR. Intresse: förebyggande av missbruk och spårbarhet. Avvägning: som B.1; lagringstiden är längre eftersom missbruksmönster blir synliga över veckor. Om IP-adressen bör avkortas eller lagringstiden förkortas är en öppen fråga för den juridiska granskningen. |
| Mottagare | Inga. Kontoinnehavare får sina egna sidvisningar i dataexporten. |
| Tredjeland | Inget. |
| Lagring | 60 dagar (nattligen mellan 03:00 och 03:05, srv/cron_status.php, inställningen ”logg över sidvisningar”). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. IP-adressen hämtas från en vidarebefordrad header endast om förfrågan kommer från vår egen föregående proxy, och då endast den post som proxyn lagt till; annars skulle vem som helst kunna ange sitt ursprung godtyckligt. |
B.3 Cookies och lagring i webbläsaren
| Fält | Uppgift |
| Ändamål | Tekniskt nödvändig lagring: session, skydd mot förfalskning av förfrågningar mellan webbplatser (CSRF), räkning av gränserna för kontroller utan konto, inloggning, förbli inloggad på begäran, ljus eller mörk visning. |
| Kategorier av registrerade | Besökare och användare av formexposed.com. |
| Kategorier av personuppgifter | Sessionscookie bpid (sessionsidentifierare; upphör när webbläsaren stängs; HttpOnly, SameSite=Lax, Secure via HTTPS). Cookie bp_remember endast efter val av ”Håll mig inloggad” (selektor och verifierare; 30 dagar). Lokal lagring bp_theme (ljus, mörk eller system). I administrationsområdet dessutom operatörernas lokala visningsinställningar. För gränserna bildas en hash av sessionsidentifieraren; själva identifieraren sparas inte. |
| Sätts inte | Inga analys-, reklam- eller spårningscookies. Partnerprogrammet (B.33) fungerar utan cookie. Märkesbilden på kundsidor sätter ingen cookie (B.18). reCAPTCHA kan sätta cookies från Google när ett skyddat formulär skickas (B.23). |
| Rättslig grund | Åtkomst till terminalutrustningen: absolut nödvändig för den tjänst som användaren begärt (§ 25(2) nr 2 TDDDG, den tyska lagen om dataskydd inom telekommunikation och digitala tjänster; Art. 399(3) PKE, den polska lagen om elektronisk kommunikation (Prawo komunikacji elektronicznej)). Behandling: Art. 6(1)(b) GDPR (konto) och (f) (säkerhet, gränser). |
| Mottagare | Inga. |
| Tredjeland | Inget. |
| Lagring | Session; 30 dagar för token för att förbli inloggad. Den nattliga körningen raderar utgångna sådana tokens i databasen (remember_tokens); vid utloggning, lösenordsbyte och återkallelse av en enhet omedelbart. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.4 Kostnadsfri kontroll utan konto – mottagande, gränser och missbruksövervakning
| Fält | Uppgift |
| Ändamål | Vem som helst kan låta kontrollera en domän utan konto. För att inmatningsfältet inte ska bli ett vapen mot tredje parters webbplatser gäller stegvisa gränser: en anonym kontroll per domän på sju dagar (därefter samma rapport), gränser per IP-adress och per session på 24 timmar, en daglig gräns för hela systemet, spärr för mycket nya domäner, spärrlista och opt-out, endast offentliga adresser. Iögonfallande mönster registreras och rapporteras till operatören. Gränserna per IP-adress, per session och för hela systemet, var och en räknad separat, gäller även för kontrollen från pluginet utan konto (ett plugin med bundet nyckelpar räknas per webbplats i stället för per adress) och för opt-out (B.30); det kostnadsfria headerverktyget (B.9) har egna gränser per IP-adress och dag och för hela systemet. |
| Kategorier av registrerade | Personer som utlöser en kontroll, en förfrågan i headerverktyget eller en opt-out; servrar där ett plugin är installerat. |
| Kategorier av personuppgifter | Logg över varje förfrågan: källa (kontroll, plugin, headerverktyg, opt-out), fullständig IP-adress, hash av sessionsidentifieraren, kontrollerad värd, land från IP-adressen, godtagen eller avvisad med orsak, tidpunkt (check_throttle). Avvikelser: typ (IP-adress, session, land, system), nyckel (för typen ”IP” den fullständiga IP-adressen), mönster, allvarlighetsgrad, kort beskrivning, tidpunkter för upptäckt och lösning, person som löste (abuse_flags). Jobb: värd, läge, förtroendenivå och en avkortad sessionshash som identifierare för den som begärt (scan_jobs). Rapport: slumpmässig identifierare, värd, språk, utgångstid, första visning, antal visningar (reports). Cachad domänålder från registeruppslaget (domain_age_cache). |
| Källa | Personens inmatning; personens förfrågan; registeruppslag (RDAP) för domänens ålder. |
| Rättslig grund | Utförande av den begärda kontrollen: Art. 6(1)(b) GDPR (användning av den kostnadsfria kontrollen enligt användarvillkoren); i andra hand (f). Gränser och övervakning: Art. 6(1)(f). Intresse: att förhindra att tjänsten används som verktyg mot tredje parters webbplatser eller som spamkanon. Avvägning: utan koppling till adressen och sessionen skulle gränserna inte kunna upprätthållas; perioden på sju dagar är lika kort som den längsta gräns som räknas utifrån den. |
| Mottagare | Google (reCAPTCHA vid inlämning, B.23). För domänens ålder frågar skannern RDAP-omdirigeringstjänsten rdap.org, som vidarebefordrar till det ansvariga registret; endast domännamnet överförs. När en avvikelse inträffar får operatören en signal via Telegram utan någon variabel (ingen värd, ingen adress). Rapporten kan ses av den som har dess slumpmässiga länk. |
| Tredjeland | USA via reCAPTCHA (B.23). |
| Lagring | Förfrågningsloggen 7 dagar (nattligen, srv/cron_status.php). Lösta avvikelser 90 dagar efter lösning; olösta finns kvar tills någon löser dem (avsnitt 10). Anonyma rapporter löper ut efter 30 dagar; den nattliga körningen raderar då rapport, jobb, kontrollresultat, formulär, resultat och bilder (fe_reports_aufraeumen()). En administratör kan manuellt frisläppa poster för en adress; detta raderar dess logg för de senaste 24 timmarna. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Nödstopp för alla anonyma kontroller i administrationsområdet; mottryck som inte tar emot nya kostnadsfria kontroller när det finns en kö. |
B.5 Crawlerns kontroll av tredje parters webbplatser
| Fält | Uppgift |
| Ändamål | Säkerhetskontroll av offentliga kontaktformulär: skydd mot spam och missbruk, egenskaper för dataskydd och tillgänglighet, inbäddade tredjepartsskript, beteende efter avvisande i cookiebannern, mobilvisning. Gäller för kontroller utan konto (B.4), för domäner i ett konto som ännu inte är verifierade och som grund för studien (B.7) och kontrollen av potentiella kunder (B.8). För verifierade domäner i ett konto agerar vi för kundens räkning (A.4). |
| Crawlerns beteende | Egen identifierare med hänvisning till crawlersidan; läser robots.txt före kontrollen och avbryter om en disallow-regel omfattar startsidan (likaså om robots.txt inte kan nås eller vid serverfel); disallow-regler för enskilda undersökvägar beaktas inte separat. Formulärpuls, hämtning av bevis, headerverktyg och sökningen efter exponerade filer läser inte robots.txt. Högst åtta offentliga sidor per kontroll, plus upp till tre sidor med klick på ”Avvisa” i cookiebannern, upp till tre sidor i mobilvy, aktiva sonderingar för verifierade domäner och upp till fem sidor bakom en inloggning (A.5); sidorna laddas en i taget, inte parallellt; endast offentliga adresser, inga interna nätverk, omdirigeringar kontrolleras på nytt; spärrlista och opt-out kontrolleras före mottagandet och en andra gång i skannern. Passiv: utan bevis på kontroll skickas ingenting för kunder (undantag: interna kontroller av våra egna test- och demodomäner, B.6). |
| Kategorier av registrerade | Operatörer av de kontrollerade webbplatserna (när de är fysiska personer, till exempel enskilda näringsidkare); personer som råkar synas på de kontrollerade sidorna. |
| Kategorier av personuppgifter | Som A.4: sidadresser och sidtitlar, formulärstruktur (fältnamn, typer och etiketter, inga fältvärden), skyddsåtgärder, tredjepartsskript (adresser; konto-ID:n för pixlar och inspelningsverktyg ersätts före lagring), cookiebannerns beteende, skärmbilder (synligt område av startsidan, formulär). Om en mottagaradress förekommer i formuläret endast dess domän (scans, forms, findings, scan_screenshots). |
| Källa | Offentligt tillgängliga sidor. |
| Rättslig grund | Art. 6(1)(f) GDPR. Intresse: att utföra den begärda säkerhetskontrollen; att uppmärksamma webbplatsoperatörer på svagheter som kan skada deras besökare. Avvägning: endast det som varje besökare ser läses, i liten omfattning och utan att något skickas; operatören kan när som helst permanent undanta sin domän utan bevis. Information enligt Art. 14 GDPR ges via crawlersidan, opt-out och integritetspolicyn; om detta räcker enligt Art. 14(5)(b) är en öppen fråga för den juridiska granskningen. |
| Mottagare | Den som utlöser rapporten och alla som denne ger den slumpmässiga länken; den lokala språkmodellen på vår egen server där formulärtypen är oklar (formulärstruktur, sidtitel och adress, formulärets synliga text). Sårbarhetsvarningar från pluginversioner förekommer aldrig i anonyma rapporter. |
| Tredjeland | Inget. |
| Lagring | Anonymt: 30 dagar (B.4). Kontroll av potentiella kunder: 90 dagar (B.8). Studie: fram till publicering (B.7). Domän i ett konto: högst 13 månader, den senaste kontrollen finns kvar; omedelbart med domänen. Interna kontroller av operatören utan domän och utan rapport (till exempel sådana som skapats från kommandoraden): ingen lagringstid (avsnitt 10). Temporära filer på skanningsservern raderas efter varje körning. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Särskilt: separat kontrollcontainer med sänkta privilegier, skrivskyddat filsystem, minnesgräns och eget nätverk; dubbel målkontroll. |
B.6 Aktiva testinlämningar
| Fält | Uppgift |
| Ändamål | Kontroll av om ett kontaktformulär godtar en inlämning utan skydd, om CAPTCHA, fälla (honeypot), token, validering av e-postadress och hastighetsbegränsning verkar på serversidan och om headers kan injiceras. |
| Förutsättning | För kunder endast för domäner för vilka bevis på kontroll har lämnats (DNS-post, metatagg, fil eller anslutet plugin); dessutom använder operatören ett internt kommandoradsverktyg för att skapa kontroller med nivån ”verifierad” för våra egna test- och demodomäner. Endast med den globala brytaren påslagen, endast för ett formulär som tillförlitligt klassificerats som allmänt kontaktformulär. Aldrig för beställningar, bokningar, registreringar, nyhetsbrev, betalningar, filuppladdningar, obligatoriska fält med verkliga personuppgifter, eller domäner som tillhör myndigheter, vårdinrättningar eller utbildningsinstitutioner. |
| Kategorier av registrerade | Kundens personal som tar emot formulärmejlen. |
| Kategorier av personuppgifter | Testinlämningen innehåller inga personuppgifter: avsändare ”FormExposed Security Scanner”, vår egen avsändaradress eller en adress under .invalid, en märkt ämnesrad och en text på sidans språk med hänvisning till crawlersidan och opt-out samt kontrollnumret. Sparat hos oss: sidans svar, resultat, en bild av uppföljningssidan (som A.4). |
| Omfattning | Högst fem inlämningar per kontroll (inställning, standard 5); återkommande med abonnemangets kontrollfrekvens, dagligen i det högsta abonnemanget. |
| Källa | Kundens instruktion. |
| Rättslig grund | Fullgörande av avtalet med kunden (Art. 6(1)(b) GDPR); inlämningarna går till kundens eget formulär. För mottagarna hos kunden: kundens organisation. |
| Mottagare | Kunden (kundens formulärmejl). |
| Tredjeland | Inget genom oss. |
| Lagring | Resultat som A.4. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Header-injektion upptäcks endast, utförs aldrig med en verklig mottagare; valideringen av e-postadress använder endast en domän som inte kan existera. |
B.7 Studien ”Index för formulärsäkerhet”
| Fält | Uppgift |
| Ändamål | Statistik om skyddet av kontaktformulär i ett land eller en bransch. Endast totalsiffror publiceras, utan namn på webbplatser; segment endast från 20 sidor med formulär. |
| Kategorier av registrerade | Operatörer av webbplatserna på listan; personer som råkar synas. |
| Kategorier av personuppgifter | Som B.5, endast passivt. Dessutom listan: värd, segment, status, jobb (study_domains); studie med titel, land, totalsiffror för resultat (studies). |
| Källa | En lista över offentliga webbplatser som sammanställts av operatören; själva sidorna. |
| Rättslig grund | Art. 6(1)(f) GDPR. Intresse: statistiska uttalanden om läget för formulärsäkerhet. Avvägning: passiv, strypt (få jobb per körning), spärrlista och opt-out gäller, publicering endast som totalsiffror, rådata raderas. |
| Mottagare | Allmänheten, endast totalsiffror. |
| Tredjeland | Inget. |
| Lagring | Rådata (kontrollresultat, formulär, resultat, bilder, jobb) raderas vid publicering (fe_studie_veroeffentlichen()). Listan över värdar med segment finns kvar därefter; det finns ingen lagringstid för den eller för studier som aldrig publiceras (avsnitt 10). Operatören beslutar vilka listor som kontrolleras och om studier publiceras. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.8 Kontroll av potentiella kunder (förvärvsläge för byråer)
| Fält | Uppgift |
| Ändamål | En byrå (Business-abonnemang) kontrollerar passivt en potentiell kunds webbplats och får en kortrapport under sitt varumärke och den passiva rapporten. Vi kontaktar ingen; byrån vidarebefordrar själv länken. |
| Kategorier av registrerade | Operatör av den kontrollerade webbplatsen; personer som råkar synas; byråns personal som utlöser kontrollen. |
| Kategorier av personuppgifter | Som B.5, endast passivt. Dessutom: arbetsyta, person som utlöser kontrollen, värd, rapportens slumpmässiga identifierare, tidpunkt (prospect_checks). |
| Källa | Byråns inmatning; offentliga sidor. |
| Rättslig grund | Art. 6(1)(f) GDPR (vårt intresse av att tillhandahålla tjänsten och byråns intresse av en välgrundad kontakt). Byråns och vår roll och byråns skyldigheter när rapporten vidarebefordras är öppna frågor för den juridiska granskningen: om byrån skickar rapporten oombedd via e-post eller ringer är det direktmarknadsföring som kräver samtycke enligt Art. 398 PKE och § 7(2) UWG (den tyska lagen mot otillbörlig konkurrens), även mellan företag. Detta är byråns ansvar; användarvillkoren förpliktar byrån i enlighet med detta. |
| Mottagare | Byrån och alla som den ger länken. |
| Tredjeland | Inget. |
| Lagring | Rapport och kontrollresultat löper ut efter 90 dagar och raderas då av den nattliga körningen (fe_reports_aufraeumen()); kontrollposten raderas efter 90 dagar i den dagliga svärmkörningen från 04:00 (srv/cron_status.php). Med arbetsytan omedelbart. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Månadskvot (inställning, standard 30); samma sida inom sju dagar ger samma rapport; opt-out gäller. |
B.9 Headerverktyg utan konto
| Fält | Uppgift |
| Ändamål | Kostnadsfritt betyg (A+ till F) för säkerhetsheaders på en domäns startsida. Två förfrågningar, ingen webbläsare, inget formulär, ingen inlämning. |
| Kategorier av registrerade | Personer som använder verktyget; operatörer av den kontrollerade domänen. |
| Kategorier av personuppgifter | Förfrågningslogg som B.4 (källa ”headers”, IP-adress, sessionshash, värd). Resultat: värd, betyg, poäng, utvärderade headers (header_checks). |
| Rättslig grund | Art. 6(1)(f) GDPR, som B.4 och B.5. |
| Mottagare | Google (reCAPTCHA, B.23). |
| Tredjeland | USA via reCAPTCHA. |
| Lagring | Förfrågningsloggen 7 dagar; resultat efter för närvarande 90 dagar (nattlig raderingskörning, delen ”header_checks”, inställningen ”headers_keep_days”). För domäner i ett konto fastställs betyget på nytt dagligen och sparas med domänen. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Gränser per IP-adress och dag; opt-out gäller. |
B.10 Kundkonton
| Fält | Uppgift |
| Ändamål | Drift av kundkonton, arbetsytor och abonnemang. |
| Kategorier av registrerade | Kunder (företag) och deras teammedlemmar med eget konto. |
| Kategorier av personuppgifter | E-postadress och normaliserad form, lösenord endast som hash, förnamn (obligatoriskt), efternamn och företag (om angivet); applikationen sparar inte adress och momsregistreringsnummer, de anges endast hos Stripe (B.26); status, språk, visningsläge, valuta, abonnemang och faktureringsstatus, Stripe-kund- och abonnemangs-ID, slut på faktureringsperioden, uppsägning vid periodens slut, bekräftelse- och återställningsidentifierare med utgångstid, ny e-postadress tills den bekräftats, tidpunkt för registrering, senaste inloggning och senaste IP-adress, tidpunkt då alla sessioner återkallades, uppgifter om tvåfaktorsinloggning (B.11), månadsrapport på/av, tidpunkt för påminnelsemejlet, upplåsningar via koder, värvningskod och värvning (users). Arbetsytor med namn, tidpunkter, status (workspaces); medlemskap med roll och anslutningsdatum (workspace_users). |
| Källa | Registrering och inställningar av personen; faktureringsstatus från Stripe. |
| Rättslig grund | Art. 6(1)(b) GDPR (avtal). Senaste IP-adress: (f) (kontosäkerhet). |
| Mottagare | Stripe (B.26); e-postleverantören för kontomejl (B.25). Medlemmar i samma arbetsyta ser de övriga medlemmarnas namn, e-postadress och roll. |
| Tredjeland | Via Stripe och e-postleverantören. |
| Lagring | Tills kontoinnehavaren raderar kontot. Vid radering försvinner innehavarens egna arbetsytor som ingen annan använder med alla domäner och deras uppgifter; arbetsytor med ytterligare medlemmar övergår till en annan medlem, i första hand till administratörer och bland dem till den som varit med längst. Medlemskap, tokens för att förbli inloggad, enheter, API-nycklar, öppna Telegram-koder, feedback på rapporter (B.35) och kontoraden raderas; ett pågående betalabonnemang avslutas först omedelbart hos Stripe, utan återbetalning (www/ajax.php, fe_konto_reste_loeschen()). En uppsägning i faktureringsområdet träder däremot i kraft vid periodens slut; därefter fortsätter kontot med det kostnadsfria abonnemanget. Vad som finns kvar anges i avsnitt 6.4. Konton som aldrig bekräftats och aldrig loggats in på raderas efter 30 dagar, såvida inte en annan medlem är kopplad till deras arbetsyta (nattlig raderingskörning, delen ”pending_accounts”). Inaktiva konton raderas inte. Om avtalet för kontot upphör på annat sätt, till exempel genom vår uppsägning, raderar vi kontot senast 30 dagar efter avtalets slut; detta görs för närvarande manuellt (åtagande i personuppgiftsbiträdesavtalet). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.11 Inloggning, enheter, andra faktor och aktivitetslogg
| Fält | Uppgift |
| Ändamål | Skydd av konton: begränsning av inloggnings- och andra lösenordsförsök, visning och återkallelse av inloggade enheter, tvåfaktorsinloggning, spårbarhet för ändringar. |
| Kategorier av registrerade | Kontoinnehavare och teammedlemmar; personer som försöker logga in, registrera sig eller ange lösenordet till en klientportal. |
| Kategorier av personuppgifter | Inloggningsförsök: IP-adress, angiven e-postadress, lyckat, tidpunkt (login_attempts). Enheter: hash av sessionsidentifieraren (aldrig själva identifieraren), koppling till token för att förbli inloggad, IP-adress, webbläsaridentifierare och den webbläsare, det operativsystem och den enhetstyp som härleds från den, tidpunkter för inloggning, senaste aktivitet och återkallelse, och för ”Visa som kund” supportpersonens identifierare (login_sessions). Tokens för ”Håll mig inloggad”: selektor, verifierare, utgångstid (remember_tokens). Tvåfaktor: hemligheten krypterad, tidpunkt för aktivering, senast använda tidssteg, återställningskoder endast som hash (i users). Aktivitetslogg: konto, arbetsyta, åtgärd, mål, detaljer, IP-adress, land, tidpunkt (audit_logs). Försöksräknare för inloggning, andra faktorn, lösenordsbekräftelse, lösenordsåterställning, registrering och lösenord till klientportaler: en HMAC-nyckel härledd från ändamålet och konto-ID:t (för en okänd adress eller vid återställning den gemena e-postadressen), IP-adressen, konto och IP-adress tillsammans, eller portal-ID:t (även tillsammans med IP-adressen), antal försök, utgångstid; e-post- och IP-adresser sparas inte där i klartext (tabellen auth_attempt_buckets). |
| Rättslig grund | Art. 6(1)(b) GDPR jämförd med Art. 32 (enhetslista, andra faktor) och (f) (inloggningsförsök, aktivitetslogg). Intresse: att skydda konton mot övertagande, att dokumentera ändringar (Art. 5(2)). Avvägning: en avkortad adress besvarar inte frågan ”var det jag?”; aktivitetsloggen måste överleva en tvist som uppstår först månader senare. |
| Mottagare | Inga. Kontoinnehavaren ser sina enheter och får inloggningsförsök, enheter och aktiviteter i dataexporten; under en session med ”Visa som kund” förekommer varken supportpersonens IP-adress eller webbläsare där. |
| Tredjeland | Inget. |
| Lagring | Inloggningsförsök 7 dagar; efter en lyckad inloggning raderas de misslyckade försöken från samma adress omedelbart. Försöksräknare vid slutet av sitt tidsfönster (för närvarande 15 minuter, en timme för lösenordsåterställning och registrering); utgångna raderas vid nästa åtkomst och av den nattliga körningen. Enheter 90 dagar efter senaste användning eller efter återkallelse (nattlig raderingskörning, delen ”sessions”), omedelbart med kontot. Tokens för att förbli inloggad löper ut efter 30 dagar. Aktivitetsloggen 365 dagar (nattligen); när ett konto raderas finns dess poster kvar till slutet av lagringstiden (avsnitt 6.4). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.12 Bevis på avtalsslut
| Fält | Uppgift |
| Ändamål | Att bevisa vilken version av användarvillkoren, personuppgiftsbiträdesavtalet och integritetspolicyn en kund godtog eller tog del av vid registreringen, och att kunden använder tjänsten för sin näringsverksamhet. |
| Kategorier av registrerade | Kunder. |
| Kategorier av personuppgifter | Per dokument: konto, dokument, version (hash av den visade texten), tillfälle, IP-adress, webbläsaridentifierare, tidpunkt (legal_consents). Själva den visade versionen med fullständig text, språk, titel och adress, en gång per version (legal_versions; innehåller inga personuppgifter). |
| Rättslig grund | Art. 6(1)(b) och (f) GDPR (bevis på avtalsslut, försvar mot anspråk). |
| Mottagare | Inga. Kontoinnehavaren får sina poster i dataexporten. |
| Tredjeland | Inget. |
| Lagring | Så länge kontot finns; efter att kontot raderats fyra år från godkännandet, därefter raderat nattligen (srv/cron_status.php). Motivering i koden: treårig preskriptionstid från årets slut, avrundad uppåt. Om polsk rätt talar för en annan period ingår i den juridiska granskningen. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Om något av de tre dokumenten saknas är registreringen stängd. |
B.13 Teaminbjudningar
| Fält | Uppgift |
| Ändamål | Att bjuda in ytterligare personer till en arbetsyta. |
| Kategorier av registrerade | Inbjudna. |
| Kategorier av personuppgifter | E-postadress, roll, inbjudningsidentifierare, inbjudande person, utgångstid, tidpunkt för godkännande (workspace_invites); inbjudningsmejlet i utkorgen (B.25). |
| Källa | Angivet av den inbjudande medlemmen. |
| Rättslig grund | Art. 6(1)(b) GDPR i förhållande till kunden; gentemot den inbjudna personen (f) (kundens intresse av att involvera sitt team). |
| Mottagare | E-postleverantören (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tredjeland | Via e-postleverantören. |
| Lagring | En inbjudan gäller i 14 dagar och endast så länge den inbjudande personen är ägare eller administratör av arbetsytan. Inbjudningar som inte godtagits efter utgångstiden, godtagna 30 dagar efter godkännandet (nattligen, srv/cron_status.php och delen ”invites” i cfg/fristen_lib.php). Med arbetsytan omedelbart. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.14 ”Visa som kund” för support
| Fält | Uppgift |
| Ändamål | En superadministratör ser applikationen så som en kund ser den, för att lösa en supportfråga (”knappen saknas hos mig”). |
| Kategorier av registrerade | Den berörda kunden; superadministratören. |
| Kategorier av personuppgifter | Allt som kunden ser i applikationen. Loggas: en separat enhetsrad med superadministratörens identifierare (login_sessions), start och slut i aktivitetsloggen (audit_logs). |
| Rättslig grund | Art. 6(1)(b) GDPR (support som en del av tjänsten), alternativt (f). |
| Begränsningar | Högst en timme, därefter fullständig utloggning. När visningen avslutas loggas superadministratören också ut helt, inklusive den session som hen kom från; hen kommer tillbaka till administrationsområdet endast genom att logga in på nytt med lösenord och andra faktor. Avslutas omedelbart om superadministratören nedgraderas eller spärras. Allt som ändrar kundens konto är spärrat: lösenord, e-postadress, andra faktor, enheter, abonnemang, export, radering, överlåtelse. Administrationsområdet är stängt under sessionen. Kunden ser åtkomsten i sin enhetslista och i dataexporten som supportåtkomst. |
| Mottagare | Inga. |
| Tredjeland | Inget. |
| Lagringstid | Enhetsrad 90 dagar, aktivitetslogg 365 dagar. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.15 Domäner, bevis på kontroll och övervakning
| Fält | Uppgift |
| Ändamål | Kärntjänsten för kunder: att hålla domäner i kontot, lämna bevis på kontroll, kontrollera regelbundet och upptäcka förändringar. Hit hör formulärpulsen (en lätt förfrågan utan webbläsare var 10:e till 30:e minut beroende på plan), den dagliga bevakningen av e-post-DNS och certifikat, domänens utgångsdatum, spärrlistor, exponerade filer, versioner som syns utifrån, skriptinventering, visuella förändringar i formuläret, avbrott hos CAPTCHA- och e-postleverantörer samt sårbarhetsbevakningen för formulärtillägg. |
| Kategorier av registrerade | Kunder och deras teammedlemmar; innehavare av domänerna, i den mån de är fysiska personer. |
| Kategorier av personuppgifter | Domän med värd, offentlig identifierare, anteckning, kundetikett, typ och identifierare för beviset, kontrollfrekvens, övervakning på/av, underhållsfönster, värde per förfrågan, identifierare för märke, leveranskontroll och deploy-hook, tilläggsnyckel, status och senaste resultat för bevakningarna (DNS, certifikat, äkthet för formulärets e-post, spärrlistor, exponerade filer, headers, versioner) (domains). Puls per formulärsida (form_pulse). Sårbarheter utifrån tilläggsversioner (vuln_hits). Skriptinventering med adress, hash, storlek, godkännande med godkännande person och skäl (script_inventory, script_changes). Kontroller som A.4. För exponerade filer lagras sökväg, allvarlighetsgrad och typ, aldrig innehållet. |
| Förfrågningar till tredje parter | DNS-förfrågningar (SPF, DMARC, MX, bevispost). Registeruppslag via RDAP enligt IANA-katalogen: endast domännamnet. DNS-spärrlistor (SpamCop, PSBL, Mailspike, SURBL; Spamhaus endast med lagrade åtkomstuppgifter, för närvarande inte): IP-adresser till webb- och e-postservern samt domännamnet, inga besökaruppgifter. Google Web Risk endast om det är konfigurerat (för närvarande inte): startsidans adress. Tidsstämplingsmyndighet: endast ett hashvärde (B.19). WPVulnerability: endast identifieraren för ett tillägg eller tema, eller WordPress-versionen; jämförelsen med den installerade tilläggsversionen gör vi själva. Statussidor för Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun och Brevo: inget överförs utom själva förfrågan. |
| Källa | Kunden; förfrågningar till kundens sida; offentliga kataloger. |
| Rättslig grund | Art. 6(1)(b) GDPR. |
| Mottagare | De nämnda tjänsterna tar inte emot några personuppgifter om våra kunder, i den mån ett företags domännamn och serveradresser inte är personuppgifter; för enskilda näringsidkare kan domännamnet vara en personuppgift. Medlemmar i arbetsytan ser domänen. |
| Tredjeland | Förfrågningarna kan nå tjänster i tredjeländer (t.ex. registeruppslag, spärrlistor). Endast det som anges på raden ”Förfrågningar till tredje parter” överförs. |
| Lagringstid | Tills domänen raderas. fe_domain_loeschen() raderar då omedelbart kontrollresultat, formulär, fynd, bilder, rapporter, jobb, larmmål och larmlogg, incidenter, Telegram-koder, leveranser, puls, sårbarheter och bevis; via främmande nycklar övervakade formulär, webbläsarkörningar, testkonto och formulärräknare; värdens tilläggsdata om ingen annan domän hänvisar till den. Dessutom raderas domänens skriptinventering och skriptändringar; de har ingen egen lagringstid (avsnitt 6.4). Kontrollresultat högst 13 månader, det senaste finns kvar. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Bevakning av exponerade filer och versioner endast för verifierade domäner, högst en förfrågan per sökväg, endast de första 8 KB; att sondera tredje parters sökvägar utan förfrågan vore ett angreppsverktyg. |
B.16 Larm, incidenter och eskalering till kontoinnehavaren
| Fält | Uppgift |
| Ändamål | Att informera kunden om fel och förändringar, beakta underhållsfönster, kvittera och eskalera incidenter. När målen är tredje parter agerar vi för kundens räkning (A.3); när det är kontoinnehavaren själv beskrivs det här. |
| Kategorier av registrerade | Kontoinnehavare och teammedlemmar som mottagare. |
| Kategorier av personuppgifter | Som A.3. Aviseringar visas på kontoinnehavarens språk. |
| Rättslig grund | Art. 6(1)(b) GDPR. |
| Mottagare | E-postleverantör; valda chattjänster (4.1). |
| Tredjeland | Beroende på kanal (4.1). |
| Lagringstid | Som A.3: leveranslogg 90 dagar, sammanfattande aviseringar 30 dagar efter leverans, incidenter tills de är lösta och därefter 180 dagar. Larmmål tillsammans med domänen. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.17 Månadsrapport till konton
| Fält | Uppgift |
| Ändamål | Den 1:a varje månad från kl. 08:00 (efterskick till och med den 3:e), ett e-postmeddelande per konto som omfattar alla dess domäner: nivå, poäng och förändring, larm, blockerade botar, e-postutskick, jämförelsevärde. |
| Kategorier av registrerade | Aktiva kontoinnehavare med månadsrapporten påslagen. |
| Kategorier av personuppgifter | E-postadress, språk, nyckeltal för domänerna. |
| Rättslig grund | Art. 6(1)(b) GDPR (del av tjänsten). Kan avbeställas i inställningarna; kan stängas av centralt. |
| Mottagare | E-postleverantör (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tredjeland | Via e-postleverantören. |
| Lagringstid | Ingen separat lagring; e-postmeddelandet ligger kvar i utkorgen i 30 dagar (B.25). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.18 Märke och offentlig bekräftelsesida
| Fält | Uppgift |
| Ändamål | En kund kan bädda in en märkesbild på sin webbplats och länka den till en offentlig bekräftelsesida. Märket visar ”Skyddat” endast om domänen är verifierad, övervakningen är igång och den senast slutförda kontrollen är högst 45 dagar gammal och gav resultatet ”Skyddat” eller ”Delvis skyddat”; annars visar det neutralt ”Kontroll av kontaktformulär”. Bekräftelsesidan anger nivå och datum, inga enskilda fynd. |
| Kategorier av registrerade | Besökare på kundens webbplats vars webbläsare laddar bilden; besökare på bekräftelsesidan. |
| Kategorier av personuppgifter | När bilden laddas: IP-adress, tidpunkt, begärd adress, hänvisande sida och webbläsaridentifierare i webbserverloggen (B.1). Bildadressen startar ingen session, sätter ingen cookie och skriver inte till loggen över sidvisningar. Bekräftelsesidan är en vanlig sida (B.2, B.3). |
| Rättslig grund | Art. 6(1)(f) GDPR. Intresse: att leverera bilden och hålla driften säker. Huruvida kunden och vi är gemensamt personuppgiftsansvariga för överföringen av besökarens IP-adress, i den mening som avses i rättspraxis om inbäddat innehåll från tredje part, och huruvida ett arrangemang enligt Art. 26 krävs, är en öppen fråga för den juridiska granskningen. Kunden får ett textförslag till sin integritetspolicy. |
| Mottagare | Inga. |
| Tredjeland | Inget. |
| Lagringstid | 14 dagar (webbserverlogg). Bilden cachas i en timme. När märket stängs av upphör identifieraren att gälla. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.19 Bevislogg och tidsstämpel
| Fält | Uppgift |
| Ändamål | En logg per domän och månad (betalda planer): vad som kontrollerades, med vilket resultat, vad som rapporterades och vad som ändrades, som bevis för ansvarsskyldigheten, försäkringsgivare eller leverantörsrevisioner. Varje version får ett kontrollnummer; en offentlig sida bekräftar domän, period och nyckeltal, inga detaljer. Sedan den 7 oktober 2026 bekräftar en tidsstämplingsmyndighet enligt RFC 3161 tidpunkten. |
| Kategorier av registrerade | Kunder; indirekt personer som kan nämnas i loggen som godkännare eller kvitterare. |
| Kategorier av personuppgifter | Domän, månad, kontrollnummer, innehållshash (SHA-512), sammanfattning och data i loggen, tidsstämpelsvar, tidsstämplingsmyndighet och tidpunkt, misslyckade försök (proof_docs). |
| Rättslig grund | Art. 6(1)(b) GDPR. |
| Mottagare | Tidsstämplingsmyndigheten (standard Certum, reserv DigiCert) tar emot endast hashen av loggen, inte dess innehåll. Offentligt: nyckeltal via bekräftelsesidan. Kunden och alla som kunden ger loggen eller kontrollnumret till. |
| Tredjeland | Ingen överföring av personuppgifter: en hash tillåter inga slutsatser om innehållet. Reservmyndigheten har sitt säte i USA. |
| Lagringstid | Tills domänen raderas (fe_domain_loeschen()). Tidsstämpeln är inte en kvalificerad tidsstämpel enligt eIDAS. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.20 Tillägg och extension: kontroll, anslutning och överföring
| Fält | Uppgift |
| Ändamål | WordPress-tillägget och TYPO3-extensionen kan begära en kontroll (även utan konto), ansluta till ett konto (installationen räknas som bevis på kontroll med ett klick i kontot), låsa upp skyddsfunktioner, rapportera siffror dagligen (A.9) samt omedelbart rapportera e-postfel och underhållsläge. |
| Kategorier av registrerade | Kunder; innehavare av webbplatser som använder tillägget utan konto. |
| Kategorier av personuppgifter | Per värd: tilläggs- och CMS-version, antal kontroller, senaste rapportidentifierare, hash av anslutningshemligheten, första och senaste kontakt (plugin_sites). Engångskoder för anslutning som hash med utgångstid (plugin_connect_tokens). En byrås utrullningskoder som hash med prefix, etikett, användningar, skapande person (workspace_connect_codes). Förfrågningslogg med IP-adressen till den anropande servern (B.4). Tilläggsnyckeln är offentligt synlig i webbplatsens head; den är en hash av hemligheten, och själva hemligheten lagras endast som hash och returneras aldrig. |
| Rättslig grund | Art. 6(1)(b) GDPR (konto); utan konto (f) (begärd kontroll, förebyggande av missbruk). |
| Mottagare | Inga. |
| Tredjeland | Inget. |
| Lagringstid | En värds data raderas så snart ingen domän längre hänvisar till den; raden för ett tillägg utan konto först efter 90 dagar utan kontakt (nattlig raderingskörning, del ”orphan_hosts”). Engångskoder en dag efter utgång. Utrullningskoder tillsammans med arbetsytan. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Sedan den 27 september 2026 accepterar servern endast nyckelpar som är bundna till webbplatsen; äldre, obundna anslutningshemligheter har raderats. |
B.21 Svärmskydd
| Fält | Uppgift |
| Ändamål | Gemensamt skräppostförsvar: anslutna webbplatser rapporterar domänerna för länkar i meddelanden som deras skyddslager har stoppat. En domän som förekommer på minst tre webbplatser med minst fem träffar inom sju dagar sätts upp på en lista som går tillbaka till alla anslutna webbplatser; deras skyddslager flyttar meddelanden med sådana länkar till karantän, aldrig ut i intet. |
| Kategorier av registrerade | Innehavare av de rapporterade länkdomänerna, i den mån de är fysiska personer (t.ex. den som driver en skräppostwebbplats i eget namn). Inte avsändare och mottagare av meddelandena: adresser, texter och namn rapporteras inte. |
| Kategorier av personuppgifter | Signaler: typ, domän, rapporterande värd, dag, träffar (swarm_signals). Lista: typ, domän, antal webbplatser och träffar, tidpunkter (swarm_list). Stora tjänster, våra kunders domäner och undantag som operatören har angett listas aldrig. |
| IP-nät | Delning av IP-nät (/24, /48) har förberetts. Den är avstängd och tillägget rapporterar inga; den slås på först efter en juridisk granskning, eftersom IP-adresser är personuppgifter. |
| Rättslig grund | Art. 6(1)(f) GDPR. Intresse: att skydda alla kunders formulär mot skräppostvågor. Intresseavvägning: endast domäner, minimitrösklar mot förgiftning, inga förlorade meddelanden, borttagning möjlig när som helst. |
| Mottagare | Alla anslutna webbplatser (listan över domäner). |
| Tredjeland | Beroende på var de anslutna webbplatserna finns; listan kan även nå webbplatser utanför EES. Den utgör personuppgifter endast i gränsfall (domäner som tillhör fysiska personer). Grunden för överföring enligt kapitel V GDPR i dessa fall återstår att fastställa (öppen fråga för den juridiska granskningen). |
| Lagringstid | Signaler 30 dagar (daglig svärmkörning från kl. 04:00, cfg/swarm_lib.php). Listan beräknas om dagligen; det som inte längre når tröskeln faller bort. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.22 API-nycklar, programmeringsgränssnitt och MCP-server
| Fält | Uppgift |
| Ändamål | Åtkomst för kundens egna verktyg (REST API, Zapier, Make, MCP-server för AI-assistenter) till kundens domäner, kontroller och incidenter. |
| Kategorier av registrerade | Kunder som skapar nycklar. |
| Kategorier av personuppgifter | Nyckel endast som hash, prefix, etikett, tidpunkter för skapande, senaste användning och återkallelse (api_keys). Anrop per minut (api_usage). |
| Rättslig grund | Art. 6(1)(b) GDPR. |
| Mottagare | Det verktyg som kunden förser med nyckeln; kunden bestämmer vilket. |
| Tredjeland | Beroende på kundens verktyg. |
| Lagringstid | Nycklar tills de återkallas, omedelbart tillsammans med kontot; nycklar utan konto (äldre data) nattligen. Anropsräknare efter en dag (ibland rensas de vid ett anrop). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.23 reCAPTCHA och vårt eget formulärskydd
| Fält | Uppgift |
| Ändamål | Försvar mot automatiserad åtkomst till våra egna formulär: gratis kontroll, header-verktyg, opt-out, inloggning, registrering, glömt och återställt lösenord, support och kontakt. Dessutom vårt eget skydd utan tredje parter: fälla (dolt fält), signerad tidskontroll och CSRF-token. Sedan den 29 oktober 2026 därutöver vårt formulärskydd formconfirmed (beräkningsbevis och kontrolltoken för engångsbruk) för den gratis kontrollen, registreringen, inloggningen och ”glömt lösenord”. |
| Kategorier av registrerade | Personer som skickar in dessa formulär. |
| Kategorier av personuppgifter | Hos Google: IP-adress, webbläsar- och enhetsdata, beteendedata, Google-cookies. Hos oss: Googles bedömning (poäng och åtgärd) endast i kontrollögonblicket, utan lagring, inte ens när en inskickning avvisas. För vårt eget formulärskydd: IP-adress (lagras endast förkortad och hashad), sida, tidpunkter, fällfält ifyllt ja/nej; inget innehåll. |
| Tidpunkt | Googles skript laddas först när ett skyddat formulär skickas in, inte när sidan öppnas. Vårt eget formulärskydd hämtar sin uppgift när sidan öppnas och utför beräkningen så snart formuläret används. I utvecklingssystemet är reCAPTCHA avstängt. |
| Rättslig grund | Art. 6(1)(f) GDPR. Intresse: skydd mot botar, särskilt för den gratis kontrollen, som annars skulle kunna användas mot tredje parters webbplatser. Huruvida åtkomsten till terminalutrustningen kräver samtycke enligt § 25 TDDDG eller Art. 399 PKE, trots att skriptet laddas först vid inskickning, är en öppen fråga för den juridiska granskningen. Vårt eget formulärskydd sätter inga cookies, lagrar ingenting i webbläsaren och skapar inget fingeravtryck; det ska på sikt ersätta reCAPTCHA. |
| Mottagare | Google Ireland Limited; Google LLC. För vårt eget formulärskydd inga. |
| Tredjeland | USA (endast reCAPTCHA). Grund: certifiering enligt ramen för dataskydd mellan EU och USA (EU-US Data Privacy Framework) eller standardavtalsklausuler; ska dokumenteras i detalj. |
| Lagringstid | reCAPTCHA: ingen lagring hos oss; hos Google enligt dess regler. Eget formulärskydd: hashad identifierare 1 timme, förbrukade kontrolltoken högst 11 minuter, kontrollresultat utan IP-adress 30 dagar. |
| Avbrott | Om Google inte svarar inom tre sekunder eller svarar med ett oanvändbart svar avvisas inskickningen; detsamma gäller en tom token och ett svar för en annan åtgärd än formulärets. Kontrollen hoppas över endast när reCAPTCHA är avstängt. För vårt eget formulärskydd avvisas en inskickning utan giltig kontrolltoken; om tjänsten inte gick att nå för uppgiften tillåts den. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.24 Support och kontaktformulär
| Fält | Uppgift |
| Ändamål | Att ta emot och besvara förfrågningar via supportfönstret och kontaktsidan. Båda använder samma väg och samma tabell. |
| Kategorier av registrerade | Personer som skickar förfrågningar, inloggade eller inte. |
| Kategorier av personuppgifter | Konto (om inloggad; då gäller kontots adress, inte den angivna), e-postadress, anledning från en fast lista, text på upp till 4 000 tecken, status, fullständig IP-adress, land, webbläsaridentifierare, hänvisande sida (endast egna sökvägar), språk, tidpunkter för mottagande och svar (support_requests); post i aktivitetsloggen (utan text); mottagningsbekräftelse till den som skickat förfrågan i utkorgen (B.25), med texten upp till 2 000 tecken endast för inloggade avsändare, utan texten för förfrågningar som görs utan inloggning. |
| Rättslig grund | Art. 6(1)(b) GDPR när förfrågan gäller ett avtal; annars (f). Fullständig IP-adress: (f) (gräns på tre förfrågningar per timme och adress, förebyggande av missbruk). |
| Mottagare | E-postleverantör (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) för bekräftelse och svar. Telegram tar emot en fast signal utan någon variabel (”det finns en ny supportförfrågan”) och därmed inga personuppgifter. |
| Tredjeland | Via e-postleverantören. |
| Lagringstid | 24 månader (nattlig raderingskörning, del ”support”); manuellt tidigare. När ett konto raderas finns förfrågningarna kvar till slutet av lagringstiden (avsnitt 6.4). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. reCAPTCHA, vårt eget formulärskydd, hastighetsbegränsning. |
B.25 Utskick av e-post (utkorg)
| Fält | Uppgift |
| Ändamål | Transaktionella e-postmeddelanden: bekräftelse av registrering och av nya e-postadresser, återställning av lösenord, inbjudningar, larm, månadsrapporter, portalbekräftelser och portalrapporter, supportbekräftelser och supportsvar, påminnelser om provperioden och konfigurationen, driftaviseringar till operatörerna. Ingen reklam, inga e-postmeddelanden till personer som inte själva har registrerat sig eller angetts som mottagare av kunden. |
| Kategorier av registrerade | Mottagare av dessa e-postmeddelanden. |
| Kategorier av personuppgifter | Mottagaradress, ämne, fullständigt innehåll, svarsadress, ändamål, utskicksväg, status, fel, försök, tidpunkter (mail_outbox). Innehållet kan omfatta bekräftelse- och återställningslänkar med giltiga identifierare. |
| Rättslig grund | Art. 6(1)(b) GDPR; för driftaviseringar (f). |
| Mottagare | Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (utskick); kontoinnehavaren ser sina skickade e-postmeddelanden i dataexporten (utan innehåll). |
| Tredjeland | Beroende på var e-postleverantören behandlar uppgifterna; avtal och överföringsgrund ska fortfarande dokumenteras (avsnitt 4). |
| Lagringstid | 30 dagar (nattligen, srv/cron_status.php). Denna tid är medvetet den kortaste av loggarna: en lång utskickslogg skulle vara en samling giltiga nycklar. Statuskörningen kontrollerar var femte minut om ett nytt försök ska göras. |
| Status | E-postutskick måste vara konfigurerat före lanseringen. Tills e-postleverantören, med säte och grund, har fastställts visar de juridiska texterna en markering. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Misslyckade e-postmeddelanden skickas på nytt med ökande intervall och ges upp efter ett maximalt antal försök. |
B.26 Betalningar och fakturering
| Fält | Uppgift |
| Ändamål | Att ingå och hantera abonnemang (månadsvis eller årsvis i förskott), 14 dagars provperiod utan kort med en påminnelse tre dagar före slutet, betalning mot faktura för årsabonnemang (avstängt som standard), upplåsningar via värd- och partnerkoder utan betalning, fakturering, lagring för skatteändamål. |
| Kategorier av registrerade | Kunder. |
| Kategorier av personuppgifter | Hos Stripe: e-postadress, namn, faktureringsadress, momsregistreringsnummer, betalningsuppgifter, fakturor; som metadata vårt konto-ID och planen. Hos oss: Stripe-kund- och abonnemangs-ID, plan, status, periodens slut, uppsägning vid periodens slut (users); mottagna Stripe-händelser endast med identifierare, typ, status och tidpunkter, utan innehåll (stripe_events); inlösen av värdkoder med konto, kampanj och utgång (bundle_redemptions). Kortuppgifter når aldrig oss. |
| Källa | Kunden i Stripes kassa; händelser från Stripe. |
| Rättslig grund | Art. 6(1)(b) GDPR; för lagring för skatteändamål (c). |
| Mottagare | Stripe Payments Europe Limited (Irland); Stripe, Inc. (USA). För delar av betalningshanteringen agerar Stripe på eget ansvar; den exakta rollfördelningen ingår i den juridiska granskningen. |
| Tredjeland | USA via Stripe, Inc.; grund: Data Privacy Framework eller standardavtalsklausuler enligt Stripes villkor. |
| Lagringstid | Faktureringsfält tillsammans med kontot; ett löpande abonnemang avslutas innan kontot raderas. Fakturor och faktureringsunderlag enligt polsk skattelagstiftning i fem år från utgången av det år då skatteinbetalningsfristen löpte ut; de förvaras hos Stripe och kan hämtas i Stripes kundportal. Stripe-händelser och kodinlösen har ingen lagringstid (avsnitt 6.4). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Stripe-händelser accepteras endast med giltig signatur; varje händelse behandlas en gång. |
B.27 Säkerhetskopior
| Fält | Uppgift |
| Ändamål | Återställning efter ett fel: felaktig radering, skadad migrering. |
| Kategorier av registrerade | Alla vars uppgifter finns i databasen. |
| Kategorier av personuppgifter | Fullständig, komprimerad dump av applikationsdatabasen. Skärmbilder och logotypfiler förvaras utanför databasen och ingår inte i denna säkerhetskopia. Inloggningsuppgifter för testkonton finns i den endast som chiffertext (A.5). |
| Förfarande | Nattligen kl. 03:00, efter raderingskörningen, så att säkerhetskopian inte tar med det som lagringstiderna just har raderat. Dumpen behålls först när dess innehåll har kontrollerats (avslutningskod, antal tabeller, slutrad). På söndagar läser ett återställningstest in den senaste säkerhetskopian i en tillfällig databas och jämför den tabell för tabell. Om något misslyckas skickas en signal och ett e-postmeddelande till operatörerna. |
| Rättslig grund | Art. 6(1)(f) GDPR jämförd med Art. 32(1)(c). |
| Mottagare | Inga. |
| Tredjeland | Inget. |
| Lagringstid | 14 dagar; äldre dumpar tas bort först efter en lyckad ny säkerhetskopia (cfg/backup_lib.php). Raderingar som sker under denna tid når säkerhetskopian först när den löper ut; om data återställs från en säkerhetskopia tillämpas raderingsbegäranden på nytt efteråt. |
| Plats | Säkerhetskopiorna förvaras för närvarande på samma plats som databasen och är inte separat krypterade; en krypterad kopia på en andra plats är planerad (avsnitt 8.1 och 10). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.28 Fellogg och fellarm
| Fält | Uppgift |
| Ändamål | Att hitta och åtgärda fel innan en kund rapporterar dem. Nya feltyper och felvågor rapporteras till operatörerna, plus en daglig översikt från kl. 08:00. |
| Kategorier av registrerade | Användare vars förfrågan orsakar ett fel; indirekt personer vars uppgifter förekommer i ett felmeddelande. |
| Kategorier av personuppgifter | Nivå, källa, meddelande, kontext som JSON, sessionens konto-ID, tidpunkt (error_logs). Feltyper: fingeravtryck, mönster (från vilket e-postadresser, adresser, nummer och identifierare har tagits bort), ett oförändrat exempelmeddelande på upp till 2 000 tecken, första och senaste förekomst, antal (error_kinds). |
| Rättslig grund | Art. 6(1)(f) GDPR (driftsäkerhet, Art. 32). |
| Mottagare | Operatörerna via e-post genom e-postleverantören: vid en ny feltyp källa och råtext för meddelandet upp till 400 tecken (inte rensad), plus det dagliga översiktsmejlet; vid en felvåg skickas endast Telegram-signalen. Telegram tar endast emot fasta meningar utan variabler (”En ny feltyp har uppstått”, ”Många fel på kort tid”). |
| Tredjeland | Via e-postleverantören. |
| Lagringstid | Fellogg 90 dagar (nattligen). Feltyper utan lagringstid (avsnitt 10). Fellarmet är påslaget i produktionssystemet och avstängt i utvecklingssystemet. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.29 Driftsignaler och statusövervakning
| Fält | Uppgift |
| Ändamål | Att upptäcka avbrott: var femte minut en kontroll av komponenterna (startsida, databas, diskutrymme, skannerns hjärtslag, köeftersläpning), statussida, signal vid fel och vid återställd drift, hjärtslag till en extern övervakningstjänst så att även ett totalt avbrott upptäcks; eftersläpning före skannern. |
| Kategorier av registrerade | I regel inga. |
| Kategorier av personuppgifter | Inga. Dagliga rader per komponent med antal kontroller och senaste fel (system_status_logs), skannerns hjärtslag (scanner_heartbeat), dagliga nyckeltal utan personanknytning (daily_stats). Signalerna till Telegram är fasta meningar utan variabler; hjärtslaget är en förfrågan utan innehåll. |
| Rättslig grund | Inte tillämpligt, eftersom det inte finns några personuppgifter; för säkerhets skull Art. 6(1)(f). |
| Mottagare | Telegram (fasta meningar); den externa övervakningstjänsten (endast förfrågan); operatörerna via e-post. |
| Tredjeland | Telegram utanför EU; inga personuppgifter överförs. |
| Lagringstid | Statusrader 400 dagar (nattligen). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.30 Opt-out – undanta en domän
| Fält | Uppgift |
| Ändamål | Vem som helst kan permanent undanta vilken domän som helst från kontroller utan bevis; spärren gäller omedelbart för alla kontrollvägar (gratis kontroll, tillägg utan konto, studie, kontroll av potentiella kunder, header-verktyg) och även för domäner som tillhör betalande kunder med bevis på kontroll; deras pågående övervakning upphör vid nästa schemalagda kontroll. Den gäller för domänen och dess www-variant, inte för andra underdomäner. Den hävs endast av oss, på begäran och mot bevis. För att missbruk (t.ex. att en konkurrent spärrar andras domäner) ska kunna upptäckas och åtgärdas loggas spärren. |
| Kategorier av registrerade | Personer som undantar en domän. |
| Kategorier av personuppgifter | Domän, frivillig anledning på upp till 250 tecken, källa, IP-adress, land, webbläsaridentifierare, tidpunkt; vid hävning tidpunkt, person som häver spärren och skäl (blocklist). Förfrågningslogg som B.4. |
| Rättslig grund | För undantaget Art. 6(1)(f) GDPR. Intresse: att permanent och över alla kontrollvägar ge verkan åt önskemålet att en domän inte ska kontrolleras. Om den som undantar domänen själv är registrerad ger undantaget samtidigt verkan åt hens invändning enligt Art. 21 (Art. 6(1)(c)). För adress, land och webbläsaridentifierare (f) (upptäckt av missbruk). |
| Mottagare | Google (reCAPTCHA, B.23). |
| Tredjeland | USA via reCAPTCHA. |
| Lagringstid | IP-adress, land och webbläsaridentifierare efter 12 månader (nattlig raderingskörning, del ”optout_ip”). Själva undantaget finns kvar permanent, så att det får verkan. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Många spärrar från ett land inom kort tid genererar en avvikelse (B.4). |
B.31 Påminnelse efter registrering
| Fält | Uppgift |
| Ändamål | Ett enda e-postmeddelande två till 14 dagar efter registreringen till bekräftade konton utan bekräftad domän: ”Lägg till webbplats” eller ”Bekräfta domän”. Inget erbjudande, inget pris, ingen uppgradering; med upplysningen att det inte kommer att skickas igen. Vardagar kl. 09:00 till 18:00, högst 50 per körning. |
| Kategorier av registrerade | Nya kontoinnehavare. |
| Kategorier av personuppgifter | E-postadress, språk, tidpunkt för utskick (fältet ”påminnelse skickad” i users), domän och bekräftelsestatus. |
| Rättslig grund | Art. 6(1)(b) GDPR (upplysning om konfigurationen av det egna kontot). Huruvida e-postmeddelandet räknas som ett meddelande om avtalsförhållandet eller som kommersiell information som skulle kräva samtycke (Art. 10 UŚUDE, den polska lagen om tillhandahållande av tjänster på elektronisk väg (ustawa o świadczeniu usług drogą elektroniczną); Art. 398 PKE; § 7 UWG) är en öppen fråga för den juridiska granskningen; operatören kan stänga av det centralt. |
| Mottagare | E-postleverantör (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). |
| Tredjeland | Via e-postleverantören. |
| Lagringstid | Tidpunkten lagras lika länge som kontot finns; e-postmeddelandet 30 dagar i utkorgen. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Tidpunkten sätts före utskicket, så att ett avbrott inte utlöser ett andra e-postmeddelande. |
B.32 Telegram-bot för kundlarm
| Fält | Uppgift |
| Ändamål | En Telegram-chatt kopplas som larmmål: kunden får en länk till vår bot med en engångskod; när mottagaren trycker på ”Start” läser vår server koden från de nya meddelandena till boten och lagrar chatt-ID:t. Ingen öppen slutpunkt på vår sida (webhook) behövs för detta. |
| Kategorier av registrerade | Kunder och de personer vars Telegram-chatt kopplas. |
| Kategorier av personuppgifter | Engångskod, domän, skapande konto, händelser, leveransläge, chatt-ID, tidpunkter (telegram_links); chatt-ID:t som mål (alerts). Telegram levererar ytterligare profiluppgifter med meddelandet; endast koden och chatt-ID:t utvärderas och lagras. |
| Rättslig grund | Art. 6(1)(b) GDPR; för tredje parter som mottagare A.3. |
| Mottagare | Telegram. |
| Tredjeland | Utanför EU, inget beslut om adekvat skyddsnivå; valet görs av kunden (4.1). Grund och information är öppna frågor för den juridiska granskningen. |
| Lagringstid | En kod gäller i 30 minuter; kopplingsrader raderas efter en dag när en ny kod skapas, öppna koder tillsammans med kontot och domänen. Chatt-ID:t som mål tills larmmålet eller domänen raderas. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.33 Partnerprogram och upplåsningskoder
| Fält | Uppgift |
| Ändamål | Ett konto kan värva nya kunder via en värvningskod och får provision på deras betalda fakturor under ett begränsat antal månader. Koden följer med i adressen fram till registreringen; ingen cookie sätts. Värdföretag och partner kan utfärda koder som låser upp en plan under en period utan betalning; en vecka före slutet får kunden en påminnelse. |
| Status | Partnerprogrammet är avstängt som standard tills partnervillkoren finns på plats. |
| Kategorier av registrerade | Partner och värvade kunder. |
| Kategorier av personuppgifter | Värvningskod, värvande partner och tidpunkt för värvningen (i users); provision med partner, kund, Stripe-faktura-ID, belopp, valuta, provision, status, tidpunkter (partner_commissions). Upplåsning med plan, slut, källa, påminnelse (i users); kampanjer och inlösen (bundle_campaigns, bundle_redemptions). |
| Rättslig grund | Art. 6(1)(b) GDPR (partneravtal); för kunden (f) (avräkning av provisionen, utan att kundens uppgifter lämnas ut till partnern utöver provisionens belopp); skatteunderlag (c). |
| Mottagare | Partnern ser sina provisioner. |
| Tredjeland | Inget. |
| Lagringstid | Värvning och upplåsning tillsammans med kontot. Provisioner och inlösen har ingen lagringstid i koden; som räkenskapsinformation omfattas provisioner av lagring för skatteändamål (avsnitt 6.4). |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.34 Kontaktpunkt för sårbarhetsrapporter
| Fält | Uppgift |
| Ändamål | Att ta emot rapporter om sårbarheter i formexposed, enligt reglerna på sidan Säkerhet och i /.well-known/security.txt. |
| Kategorier av registrerade | Rapporterande personer; personer vars uppgifter en rapport innehåller som bevis. |
| Kategorier av personuppgifter | E-postadress, namn, rapportens innehåll och bilagor, så som den rapporterande personen skickar dem. Rapporten når oss via e-post till den adress som anges där; applikationen lagrar den inte. |
| Rättslig grund | Art. 6(1)(f) GDPR (tjänstens säkerhet, Art. 32); när en rapport innehåller tredje parters personuppgifter som bevis, likaså (f), i syfte att täppa till sårbarheten. |
| Mottagare | E-postleverantör och, tills brevlådan är konfigurerad, domänvidarebefordran hos Namecheap (avsnitt 4). |
| Tredjeland | Via e-postleverantören och, fram till omställningen, vidarebefordran. |
| Lagringstid | Ingen lagringstid har fastställts eller verkställs tekniskt (avsnitt 10). Operatören har ännu inte fastställt tiden; ett självklart tillvägagångssätt vore att radera bevis från tredje part när sårbarheten är åtgärdad och att behandla korrespondensen som supportförfrågningar. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. |
B.35 Återkoppling på en rapport
| Fält | Uppgift |
| Ändamål | Att ta emot återkoppling under en rapport (”Är något fel i den här rapporten?”) för att hitta fel i formulärigenkänningen. Superadministratören klassificerar den (ny, bekräftad, åtgärdad, avvisad) och kan ladda ner rapportens kontrolldata som testfall (formulär med fält, skäl och fynd, utan skärmbilder och utan aktivt skickade texter). |
| Kategorier av registrerade | Personer som tittar på en rapport, inloggade eller inte. |
| Kategorier av personuppgifter | Kategori och kontroll från fasta listor, sidadress på upp till 500 tecken, text på upp till 1 000 tecken, språk, tidpunkt, rapportidentifierare, kontroll, värd; kontoidentifierare om inloggad; HMAC-SHA256 av IP-adressen med en hemlig nyckel för begränsningen; status, handläggare, tidpunkt för handläggning (report_feedback). Aktivitetslogg: statusändringar och nedladdningar av ett testfall. Ingen e-postadress, ingen IP-adress i klartext. |
| Rättslig grund | Art. 6(1)(f) GDPR (att hitta och åtgärda igenkänningsfel; begränsning mot missbruk). |
| Mottagare | Inga. |
| Tredjeland | Inget. |
| Lagringstid | 24 månader (nattlig raderingskörning, del ”report_feedback”); IP-adressens kontrollsumma rensas efter 2 dagar (del ”report_feedback_ip”); omedelbart när ett konto raderas. Nedladdade testfall innehåller inga uppgifter om den rapporterande personen. |
| Tekniska och organisatoriska åtgärder | Avsnitt 8. Eget formulärskydd (fälla, signerad tid, CSRF), högst 5 rapporter per timme och 20 per dag per kontrollsumma, 10 per rapport; kan endast läsas av superadministratörer. |
6. Lagring – vad den nattliga raderingskörningen omfattar och vad den inte omfattar
Det finns automatisk radering, och den har en bestämd plats. En statuskörning (srv/cron_status.php) startas var femte minut via webbserverns crontab, i produktionssystemet liksom i utvecklingssystemet. Den kontrollerar komponenterna, hämtar e-posten för leveranskontrollen, schemalägger kontroller och skickar larm. En gång om dagen, i fönstret kl. 03:00–03:04, raderar den enligt lagringstiderna och skapar därefter säkerhetskopian. Sedan den 27 september 2026 anropar den dessutom lagringskörningen i cfg/fristen_lib.php (fe_fristen_lauf()), vars delar körs oberoende av varandra: om en misslyckas fortsätter de andra, och felet registreras i felloggen.
Bevis för att körningen fungerar: utvecklingssystemets säkerhetskopieringsstatus visar en lyckad säkerhetskopia kl. 03:00 den 11 oktober 2026; säkerhetskopian skapas i samma block omedelbart efter raderingen. Körningen skriver en logg per raderad tabell endast till standardutmatningen, som crontab kastar bort; det finns ingen permanent registrering av vad som raderades och när (avsnitt 10).
De lagringstider som visas som platshållare ställs in i administrationsområdet under lagringsinställningarna. Körningen läser samma inställningar; texterna visar därför alltid den tid efter vilken uppgifterna faktiskt raderas.
6.1 Omfattas av den dagliga körningen
| Uppgifter | Lagringstid och utlösare | Plats i koden |
Logg över sidvisningar (access_logs) | 60 dagar | srv/cron_status.php |
Aktivitetslogg (audit_logs) | 365 dagar | srv/cron_status.php |
Fellogg (error_logs) | 90 dagar | srv/cron_status.php |
Utkorg (mail_outbox) | 30 dagar | srv/cron_status.php |
Token för ”Håll mig inloggad” (remember_tokens) | efter utgång (30 dagar) | srv/cron_status.php |
Inbjudningar som inte accepterats (workspace_invites) | efter utgång (14 dagar) | srv/cron_status.php |
Inloggningsförsök (login_attempts); försöksräknare (auth_attempt_buckets) | 7 dagar; räknare när deras tidsfönster löper ut (för närvarande 15 minuter, en timme för återställning av lösenord och registrering), även vid nästa åtkomst | srv/cron_status.php |
Förfrågningslogg för kontroller utan konto (check_throttle) | 7 dagar | srv/cron_status.php |
Engångskoder för anslutning av tillägget (plugin_connect_tokens) | 1 dag efter utgång | srv/cron_status.php |
Lösta avvikelser (abuse_flags) | 90 dagar efter lösning | srv/cron_status.php |
| Utgångna rapporter tillsammans med kontrollresultat, formulär, fynd, bilder och jobb (endast utan domän i ett konto) | anonyma 30 dagar, potentiella kunder 90 dagar | fe_reports_aufraeumen() |
Leveranslogg för larm (alert_log) | 90 dagar | fe_alert_log_aufraeumen() |
Statusrader (system_status_logs) | 400 dagar | srv/cron_status.php |
Samtyckesregistreringar för raderade konton (legal_consents) | när kontot har raderats och samtycket är 4 år gammalt | srv/cron_status.php |
| Kvarlevor från raderade domäner: kontrollresultat, jobb, larmdata, incidenter, Telegram-koder, leveranser, puls, sårbarheter, bevis, skriptinventering och skriptändringar | omedelbart vid nästa körning | fe_fristen_lauf(), delarna ”orphan_scans”, ”orphan_rows” |
| Tilläggsdata för värdar utan domän; tilläggsrad utan konto | omedelbart; rad efter 90 dagar utan kontakt | del ”orphan_hosts” |
Resultat från header-verktyget (header_checks) | för närvarande 90 dagar | del ”header_checks” |
| Kontrollresultat för en domän med formulär, fynd, bilder, rapporter, jobb | 13 månader; det senast slutförda per domän finns kvar | del ”old_scans” |
Webbläsarkörningar, slutförda webbläsarjobb, tidsserier (form_browser_runs, scan_jobs, form_performance) | 13 månader | delarna ”browser_runs”, ”browser_jobs”, ”form_performance” |
Formulärräknare (form_metrics), tilläggets dagliga siffror och ändringsaviseringar (plugin_stats, plugin_changes) | 13 månader | delarna ”form_metrics”, ”plugin_stats” |
Inloggade enheter (login_sessions) | 90 dagar efter senaste användning eller återkallelse | del ”sessions” |
| Accepterade inbjudningar | 30 dagar efter accepterande | del ”invites” |
Supportförfrågningar (support_requests) | 24 månader | del ”support” |
Återkoppling på rapporter (report_feedback) | 24 månader; IP-adressens kontrollsumma 2 dagar | delarna ”report_feedback” och ”report_feedback_ip” |
PDF-versioner av rapporter i cachen (var/pdf) | 7 dagar | del ”pdf_cache” |
IP-adress, land och webbläsaridentifierare i opt-out (blocklist) | 12 månader; undantaget finns kvar | del ”optout_ip” |
Portalprenumeranter (client_subscribers) | obekräftade 30 dagar; avregistrerade 3 år | del ”subscribers” |
| Konton som aldrig bekräftats, tillsammans med arbetsyta | 30 dagar utan inloggning, såvida inte en annan medlem är kopplad | del ”pending_accounts” |
| API-nycklar utan konto (äldre data) | omedelbart | del ”api_keys” |
6.2 Utanför fönstret kl. 03:00
| Uppgifter | Lagringstid och utlösare | Plats i koden |
| Kopior i leveranskontrollens kontrollbrevlåda | efter behandling, var femte minut | fe_zustellung_abholen() |
Tilldelningar i leveranskontrollen (delivery_log) | 180 dagar, vid varje hämtning | fe_zustellung_abholen() |
Testkontots chiffertext i jobb (scan_jobs) | efter körningen, senast efter en timme | skanningsserver; fe_login_aufraeumen() |
Incidenter (alert_incidents) med deras leveransförsök vid eskalering | så länge de är olösta; 180 dagar efter lösning | fe_vorfaelle_aufraeumen() i cfg/vorfall_lib.php |
Skickade sammanfattande aviseringar (alert_queue) | 30 dagar efter leverans | cfg/kanal_lib.php |
Svärmsignaler (swarm_signals) | 30 dagar, dagligen från kl. 04:00 | cfg/swarm_lib.php |
Kontroller av potentiella kunder (prospect_checks) | 90 dagar, dagligen från kl. 04:00 | srv/cron_status.php |
Telegram-kopplingskoder (telegram_links) | 1 dag, när en ny kod skapas | cfg/kanal_lib.php |
Räknare för API-anrop (api_usage) | 1 dag, ibland vid ett anrop | cfg/agentur_lib.php |
Lösta leverantörsavbrott (provider_incidents), sårbarhetscache (vuln_cache) | 90 respektive 30 dagar; inga personuppgifter | cfg/anbieter_lib.php, cfg/luecken_lib.php |
| Rådata från studier | vid publicering | fe_studie_veroeffentlichen() |
| Säkerhetskopior | 14 dagar, efter en lyckad ny säkerhetskopia | cfg/backup_lib.php |
| Webbserverloggar | 14 dagar | systemets loggrotation |
6.3 Vid radering av kunden
- Radering av en domän (
fe_domain_loeschen()): kontrollresultat med formulär, fynd och bildfiler, rapporter, jobb, larmmål, leveranslogg, sammanfattningskö, incidenter, Telegram-koder, leveranser, puls, sårbarheter, bevisloggar, domänen ur kundportaler med fast urval; via främmande nycklar övervakade formulär med webbläsarkörningar, observationer och tidsserier, testkonto, formulärräknare; värdens tilläggsdata om ingen annan domän hänvisar till den. Domänens skriptinventering och skriptändringar raderas också samtidigt; de har ingen egen lagringstid (avsnitt 6.4 och 10). Uppgifter som blivit kvar utan tillhörande domän från tiden före den 27 september 2026 rensas av den nattliga körningen (delarna ”orphan_scans”, ”orphan_rows”).
- Radering av en arbetsyta (
fe_arbeitsbereich_daten_loeschen()): dessutom varumärke inklusive logotyp, kundportaler inklusive prenumeranter, utrullningskoder, kontroller av potentiella kunder; samt inbjudningar och medlemskap.
- Radering av ett konto: ett löpande betalt abonnemang hos Stripe avslutas omedelbart, utan återbetalning; innehavarens egna arbetsytor överlåts eller raderas; medlemskap, token för att hålla sig inloggad, enheter, API-nycklar med räknare, öppna Telegram-koder och kontoraden raderas.
- Radering av ett testkonto (
fe_login_loeschen()): chiffertexten skrivs över, raden raderas, väntande jobb rensas.
6.4 Vad körningen inte omfattar
Den här listan är den viktigare. Den anger uppgifter för vilka det inte finns någon automatisk lagringstid eller som överlever en radering.
| Uppgifter | Vad som gäller | Bedömning |
Kontouppgifter inklusive senaste IP-adress (users) | tills kontoinnehavaren raderar dem; ingen radering av inaktiva konton | avtalsuppgifter; en regel för permanent inaktiva konton utan abonnemang saknas |
| Aktivitetslogg, sidvisningar, fellogg för ett raderat konto | finns kvar med konto-ID och IP-adress till slutet av sin lagringstid | avsiktligt (bevis på åtgärder även efter avslutat avtal); ID:t pekar inte längre på något konto |
| Supportförfrågningar från ett raderat konto | finns kvar i upp till 24 månader med det gamla konto-ID:t | avsiktligt; ID:t rensas inte |
| Samtyckesregistreringar för ett raderat konto | tills samtycket är 4 år gammalt (räknat från samtycket, inte från raderingen av kontot) | avsiktligt (avsnitt B.12) |
Olösta avvikelser med IP-adress (abuse_flags) | tills någon löser dem | öppen punkt (avsnitt 10) |
Feltyper med oförändrat exempelmeddelande (error_kinds) | ingen lagringstid | öppen punkt (avsnitt 10) |
Skriptinventering och skriptändringar (script_inventory, script_changes) | ingen egen lagringstid; sparas så länge domänen finns och raderas tillsammans med den | öppen punkt (avsnitt 10) |
| Prenumeranter på återkallade kundportaler | tills arbetsytan raderas | öppen punkt (avsnitt 10) |
| Återkallade API-nycklar och utrullningskoder | tills kontot eller arbetsytan raderas | endast hashar, prefix och etikett; ringa |
Lista över studievärdar (study_domains), studier som aldrig publicerats | ingen lagringstid | öppen punkt (avsnitt 10) |
| Interna kontroller utan domän och utan rapport (kontrollresultat, formulär, fynd, skärmbilder) | ingen lagringstid; ingen raderingsväg omfattar dem | öppen punkt (avsnitt 10) |
| Provisioner, kodinlösen, Stripe-händelser | ingen lagringstid | bokföringsrelevans; tiden ska fastställas enligt skattelagstiftningen |
Cachad domänålder (domain_age_cache) | ingen lagringstid | endast domännamn och registreringsdatum |
| Autentiseringsresultat för formulärets e-post med avsändardomän | tillsammans med domänen; skrivs över vid varje mottagande | se A.1 |
| Undantag i opt-out | permanent | avsiktligt; utan beständighet får inget undantag verkan |
| E-postmeddelanden i kontaktpunktens brevlåda och i den allmänna brevlådan | ingen teknisk lagringstid | öppen punkt (avsnitt 10) |
6.5 Utanför databasen
- Skärmbilder förvaras som filer utanför webbkatalogen och raderas tillsammans med sitt kontrollresultat (alla raderingsvägar ovan raderar även filerna).
- Logotypfiler för varumärken raderas när de ersätts och tillsammans med arbetsytan.
- På skanningsservern skapas en tillfällig katalog med resultat och bilder per jobb; den raderas efter varje körning, även efter ett fel.
- Säkerhetskopior förvaras på webbservern (B.27).
- Webbserverloggar med fullständig IP-adress sparas i 14 dagar (B.1).
7. Automatiserade beslut, profilering och bedömning
formexposed bedömer webbplatser, inte människor. Enligt vår bedömning fattar tjänsten inget beslut som har rättsliga följder för en person eller på liknande sätt i betydande grad påverkar hen (Art. 22(1) GDPR). Det finns dock automatiserade bedömningar och automatiska spärrar. Vi förtecknar dem så att klassificeringen kan kontrolleras.
| Mekanism | Vad den gör | Vem den berör |
| Poäng och omdöme för en kontroll | Viktad summa av saknade skyddslager (CAPTCHA, fälla, token, tidskontroll, ineffektiv CAPTCHA, känd exponerad konfiguration), 0 till 100; utifrån detta ”Exponerat”, ”Delvis skyddat” eller ”Skyddat”. Webbplatsens omdöme följer det sämsta kontaktformulär som reglerna (inte språkmodellen) har identifierat som sådant; utan kontaktformulär finns inget omdöme. Vikterna kan ställas in i administrationsområdet. | Webbplatsinnehavare; för enskilda näringsidkare indirekt en person. Omdömet har ingen rättslig följd; det är ett fynd med bevis och anvisningar. |
| Klassificering av formulärtypen | Regler först, en lokal språkmodell endast om reglerna ger ”okänd”. Avgör om en aktiv testinskickning är tillåten (endast för ett kontaktformulär som reglerna säkert har identifierat). Formulär som klassificerats av språkmodellen skickas aldrig in och räknas inte in i poäng och omdöme. | Kunden och mottagarna av hens formulärmejl; skyddseffekt: vid tvekan skickas ingenting in. |
| Märke | Visar ”Skyddat” endast under fasta villkor (B.18), annars neutralt. | Kunden; ingen effekt på besökare. |
| Begränsningar och spärrar för gratis kontroll, header-verktyg och opt-out | Avvisar förfrågningar om gränser per adress, session, domän eller system har nåtts, om domänen är för ung eller av okänd ålder, eller om den finns på spärrlistan. | De som gör förfrågningar; effekt: en kostnadsfri tjänst nekas i timmar till dagar. En administratör kan släppa en adress; förfrågningar via kontaktsidan når en människa. |
| Avvikelser | Mönster (många domäner från en adress, förfrågningsstötar, många avvisningar, många opt-outs från ett land, dagsgräns nådd) registreras och rapporteras. De spärrar inte av sig själva; spärrar följer av begränsningarna. | De som gör förfrågningar. |
| Inloggningsspärr | Efter för närvarande åtta misslyckade inloggningar från en adress inom 15 minuter avvisas inloggningar från den adressen tillfälligt. Dessutom räknas alla inloggningsförsök, även lyckade, per konto och IP-adress (för närvarande åtta), per konto över alla adresser (betydligt fler, mot distribuerad gissning) och per IP-adress (för närvarande 80) inom 15 minuter, liksom koder för andra faktorn (tio per konto inom 15 minuter); därutöver avvisas försök. Misslyckade försök från en annan adress låser därför inte längre ute ägaren från ett konto. Lösenordsbekräftelser (fem per konto inom 15 minuter), återställningsmejl (tre per adress och timme, med oförändrat svar), registreringar (tio per IP-adress och timme) och försök med lösenordet till en kundportal (tio per portal och IP-adress, 50 per portal inom 15 minuter) begränsas på samma sätt. | Personer som loggar in, registrerar sig eller öppnar en kundportal; effekten är tidsbegränsad, återställning av lösenord förblir möjlig. |
| reCAPTCHA-tröskel | Avvisar inskickningar under en Google-poäng; tröskel per användningsställe (för närvarande 0,7 för kontroll och opt-out). Svar för en annan åtgärd och inskickningar där Google inte svarar inom tre sekunder avvisas också. | Personer som skickar in våra formulär; effekt: ett nytt försök eller vägen via kontaktsidan. |
| Svärmskydd | Sätter automatiskt upp en länkdomän på en lista när minimitrösklar nås; skyddslager på anslutna webbplatser flyttar meddelanden med sådana länkar till karantän. | Avsändare av meddelanden till kunders sidor. Effekt: meddelandet hålls kvar, raderas inte, och kan släppas av webbplatsinnehavaren. Beslutet om meddelandet fattas av innehavarens tillägg på innehavarens webbplats, inte av oss. |
| Jämförelsevärden | ”Bättre skyddad än X % av kontrollerade webbplatser”, endast utifrån summor från minst 20 värdar. | Webbplatsinnehavare; ingen effekt. |
Det som ligger närmast Art. 22 är tilläggets skyddslager på kunders sidor, som automatiskt håller kvar inskickningar. Det är en behandling som webbplatsinnehavaren utför på sin egen server (A.10). Det raderar ingenting utan flyttar meddelanden till karantän, och innehavaren kan släppa vilket meddelande som helst. Ingen profilering av besökare sker där eller hos oss; det finns ingen besökaridentifierare som kopplar ett meddelande till ett annat.
8. Tekniska och organisatoriska åtgärder (Art. 32) – allmän beskrivning
Detta avsnitt är den allmänna beskrivningen enligt Art. 30(1)(g) och (2)(d) GDPR. Den utförliga versionen finns på sidan Tekniska och organisatoriska åtgärder. Varje åtgärd nedan är belagd i koden eller i konfigurationen. Åtgärder som ännu inte har genomförts finns i samma avsnitt (8.1), så att beskrivningen är fullständig.
| Område | Gällande åtgärd |
| Transportkryptering | HTTPS för webbplats, app och gränssnitt; HSTS; cookies för session och inloggningstoken endast över HTTPS, HttpOnly, SameSite=Lax. |
| Åtkomstkontroll (autentisering) | Lösenord endast som hash, nya med minst tio tecken och högst 72 byte; inloggningsspärr efter upprepade misslyckade försök samt försöksgränser per konto och IP-adress tillsammans, per konto och per IP-adress, så att misslyckade försök från en annan adress inte låser ute ägaren; försöksgränser även för lösenordsbekräftelser, återställning av lösenord (med samma svar och svarstid), registreringar och portallösenord; inloggning med två faktorer (TOTP) med krypterad hemlighet, skydd mot återanvändning av koder och hashade återställningskoder; ny sessionsidentifierare vid varje inloggning, identifierare som inte utfärdats av servern accepteras inte; ”Håll mig inloggad” inte för superadministratörer, varje token gäller endast en gång; ändring av e-postadressen ogiltigförklarar en öppen återställningslänk; enheter kan återkallas var för sig eller alla på en gång; enhetslistan innehåller endast hashen av sessionsidentifieraren. |
| Åtkomstkontroll (behörighet) | Roller per arbetsyta (ägare, admin, läsare); behörigheter kontrolleras mot objektet, aldrig mot en identifierare från formuläret; testkonto, ”Fix it for me” och aktiva kontroller endast för ägare och administratörer; ”Visa som kund” tidsbegränsat och spärrat för kontoändrande åtgärder, när det avslutas sker fullständig utloggning, återgång till administrationsområdet endast med lösenord och andra faktor; inbjudningar gäller endast så länge den inbjudande personen är ägare eller admin; adresser till webhooks och chattkanaler visas för läsare endast förkortade till värden; värdnamnet för en verifierad domän kan inte ändras. |
| Applikationssäkerhet | CSRF-token; förberedda databassatser; vårt eget formulärskydd (fälla, signerad tidskontroll); reCAPTCHA på de offentliga formulären; hastighetsbegränsning för support, kontroller och gränssnitt; endast ett ”Fix it for me”-anrop per arbetsyta åt gången, så att kvoten håller även vid samtidiga förfrågningar; Content Security Policy med inramningsskydd som endast låter skript köras som bär respektive svars frisläppande (nonce); IP-adress från vidarebefordrade headers endast från vår egen proxy och endast från den post den har lagt till; åtkomsttoken maskerade i loggen över sidvisningar. |
| Hemligheter | API-nycklar, utrullningskoder, tilläggets anslutningshemligheter, engångskoder och portallösenord endast som hash; inloggningsuppgifter för testkonton asymmetriskt krypterade, privat nyckel endast på skanningsservern; webhooks signerade; Stripe-händelser endast med giltig signatur. |
| Uppgiftsminimering | Leveranskontrollen lagrar inget innehåll och inga fullständiga avsändaradresser; mottagaradresser i formulär endast som domän; konto-ID:n i skriptadresser ersätts; tilläggets siffror endast från fasta listor; feltexter vid e-postutskick endast som kategori; Telegram-signaler utan variabler; bilder från webbläsarkontrollen med maskerad inmatning; inga skärmbilder bakom en inloggning. |
| Isolering av skannern | Varje kontroll i en egen container: alla Linux-capabilities borttagna, ingen behörighetsupptrappning, skrivskyddat filsystem, minnes- och processgräns, eget nätverk; målkontroll mot privata och lokala nätverk före godkännande och i skannern, även efter omdirigeringar; service workers blockerade, WebSocket-anslutningar stängda. Förfrågningar från webbservern (bevis på kontroll, header-verktyg, filsökning, puls, RDAP, certifikat, webhooks och chattlarm) endast på de vanliga webbportarna och endast till exakt den kontrollerade adressen, webhooks och chattlarm endast över HTTPS. |
| Lagring | Skärmbilder utanför webbkatalogen, kan endast hämtas via rapporten; rapporter på slumpmässiga adresser med noindex; katalogen för säkerhetskopior kan endast läsas av tjänsten. |
| Tillgänglighet och återställning | Nattlig säkerhetskopia med innehållskontroll, veckovis återställningstest, larm vid fel; komponentkontroll var femte minut med signal och e-post; externt hjärtslag; nödstopp för anonyma kontroller; mottryck vid eftersläpning. |
| Spårbarhet | Aktivitetslogg för inloggningar, ändringar, raderingar, supportåtkomst och godkännanden; fellogg med larm. |
| Radering | Lagringstider på ett ställe i koden, från samma inställningar som texterna (avsnitt 6); raderingskedjor för domän, arbetsyta och konto, med undantagen i avsnitt 6.4. |
| De registrerades rättigheter | Export med ett klick av alla kontouppgifter som en fil, baserad på en tillåtelselista över fält, utan hemligheter. |
| Organisation | Administrationsområdet endast för konton med superadministratörsbehörighet, spärrat under ”Visa som kund”; utvecklings- och produktionssystem åtskilda, utvecklingssystemet bakom en ytterligare åtkomstspärr; överföring av juridiska texter efter godkännande via ett verktyg som vägrar utkast och platshållare. |
8.1 Åtgärder som ännu inte har genomförts
- Ingen kryptering av databasen i vila (uppmätt den 11 oktober 2026). Undantagen är inloggningsuppgifterna för testkonton och hemligheten för andra faktorn, som är krypterade på fältnivå.
- Interna anslutningar inte genomgående krypterade. Anslutningar inom vårt interna nätverk är inte genomgående krypterade. Inloggningsuppgifter för testkonton färdas där endast som chiffertext.
- Ingen säkerhetskopia på en andra plats. Säkerhetskopiorna förvaras för närvarande på samma plats som databasen och är inte separat krypterade; en krypterad kopia på en andra plats är planerad. Till dess skyddar de mot ett felaktigt raderingskommando, inte mot förlust av platsen.
- Härdningen av serveradministrationen är inte slutförd. Säkerheten för den administrativa åtkomsten till våra servrar uppfyller ännu inte den standard vi avser för driften; härdningen pågår. Vi publicerar inga detaljer, eftersom de skulle hjälpa en angripare; vi lämnar dem till en tillsynsmyndighet på begäran.
- Ingen fungerande läslogg i administrationsområdet. Skrivåtgärder registreras i aktivitetsloggen; vem som enbart har tittat på vilken supportförfrågan eller vilken rapport kan endast fastställas utifrån loggen över sidvisningar (60 dagar).
- Ingen permanent raderingslogg. Vad den nattliga körningen har raderat registreras inte (avsnitt 6).
- Ingen oberoende andra kontrollpunkt. Sonden på en andra plats är inte konfigurerad (A.6).
9. Dataskyddsombud – bedömning enligt Art. 37 GDPR
Resultat: Enligt vår bedömning finns ingen skyldighet att utse ett dataskyddsombud. Bedömningen ingår i den juridiska granskningen och görs om så snart någon av de omständigheter som anges nedan ändras.
Art. 37(1) kräver att ett ombud utses i tre fall.
- Led (a) (myndighet eller offentligt organ) är inte tillämpligt.
- Led (b) (kärnverksamhet som kräver regelbunden och systematisk övervakning av registrerade i stor omfattning): vår kärnverksamhet är regelbunden, systematisk kontroll av webbplatser och formulär, inte observation av människor. Vi skapar inga besökarprofiler, använder ingen spårning och kopplar inget meddelande till ett annat. Leveranskontrollen (A.1) leder verkliga besökarmeddelanden genom vår brevlåda, men utvärderar endast headers och de första 8 KB för tilldelning och lagrar inget innehåll; den observerar leveransvägar, inte människor. Kundkonton och loggar är underordnade affärsverksamheten.
- Led (c) (behandling i stor omfattning av särskilda kategorier enligt Art. 9 eller av uppgifter som rör brott enligt Art. 10 som kärnverksamhet): inte uppfyllt. Särskilda kategorier kan förekomma tillfälligt i kopior av formulärmejl (A.1), på sidor bakom en inloggning (A.5) eller i inklistrad kod (A.7); tillfällig insamling är ingen kärnverksamhet.
Art. 37(4) tillåter att nationell rätt lägger till ytterligare fall. Vi låter en advokat bekräfta huruvida polsk rätt kräver att vi utser ett ombud.
Utlösare för en ny bedömning: aktivering av svärmskydd med IP-nät; en funktion som känner igen besökare över flera meddelanden eller webbplatser; lagring av innehåll från leveranskontrollen; en kund vars formulär huvudsakligen rör särskilda kategorier (hälsa, jobbansökningar) med leveranskontrollen påslagen i stor omfattning; den första anställda med åtkomst till kunduppgifter. Ett frivilligt utnämnande är fortfarande möjligt; Art. 37–39 gäller då fullt ut.
Separat: huruvida en konsekvensbedömning avseende dataskydd enligt Art. 35 krävs för enskilda behandlingar besvaras på sidan Konsekvensbedömning avseende dataskydd. Dess tröskelbedömning kommer fram till att en konsekvensbedömning krävs för svärmskyddet (B.21) och för studier i den avsedda omfattningen (B.7) och genomförs av oss, och att den för leveranskontrollen (A.1) krävs i den typiska konstellationen, som en skyldighet för kunden, som vi stöder i detta.
10. Öppna punkter och planerade åtgärder
Följande punkter är belagda i koden, schemat eller konfigurationen, inte antagna. De beskriver läget per dagen för denna version; klassificeringen är vår egen och föregriper inte någon rättslig bedömning. De är ordnade efter sin tyngd för de registrerade, inte efter hur lätta de är att åtgärda. De planerade åtgärderna och deras prioritet anges i konsekvensbedömningen avseende dataskydd.
| Öppen punkt | Vad som är belagt | Betydelse |
| E-postleverantör utan dokumenterat avtal | För Namecheap, Inc. (Private Email), Phoenix, Arizona, USA är avtal, behandlingsplatser och överföringsgrund inte dokumenterade. Kontomejl, larm och kontrollbrevlådan med verkliga besökarmeddelanden går via denna leverantör. | De relevanta bestämmelserna är Art. 28(2) och (4) samt kapitel V GDPR. Ingående och dokumentation är planerade före lanseringen. |
| Grunder för chattjänster och reCAPTCHA öppna | Larm till Telegram (inget beslut om adekvat skyddsnivå), Slack, Discord, Microsoft Teams och Google Chat; reCAPTCHA utan begäran om samtycke. | Öppna frågor för den juridiska granskningen; till dess är information och grund inte slutgiltiga. |
| Kontrollbrevlådan kan hålla meddelanden vid störningar | Radering sker efter lyckad behandling; om hämtningen misslyckas finns kopiorna kvar till nästa lyckade körning. Det finns ingen varning när en eftersläpning byggs upp i brevlådan under en längre tid. | Kopiorna innehåller verkliga förfrågningar från besökare. |
| Ingen säkerhetskopia på en andra plats, ingen kryptering av databasen i vila | Avsnitt 8.1. En krypterad kopia av säkerhetskopian på en andra plats är planerad. | En enda händelse på platsen skulle drabba uppgifter och säkerhetskopia samtidigt; ett stulet lagringsmedium skulle vara läsbart. |
| Olösta avvikelser utan lagringstid | Avvikelser med fullständig IP-adress som nyckel raderas först 90 dagar efter lösning; det som aldrig löses finns kvar. | Gäller principen om lagringsminimering (Art. 5(1)(e)); radering är beroende av manuell lösning. En fast lagringstid är planerad (åtgärder i konsekvensbedömningen avseende dataskydd). |
| Feltyper med exempelmeddelande utan lagringstid | Exempelmeddelandet lagras oförändrat upp till 2 000 tecken; det rensade mönstret tar bort adresser och nummer, exemplet gör det inte. | Felmeddelanden kan innehålla e-postadresser, värdnamn eller IP-adresser. |
| Skriptinventering utan egen lagringstid | Skriptinventering och skriptändringar raderas tillsammans med domänen (FE_DOMAIN_TABELLEN), även när arbetsytan eller kontot raderas och i den nattliga körningen för kvarlevor; de har ingen egen lagringstid. De innehåller skriptadresser, sidadresser och, för godkännanden, den godkännande personen och ett skäl i fritext. | Gäller principen om lagringsminimering (Art. 5(1)(e)); ändringsloggen med godkännandena växer så länge domänen finns. |
| Prenumeranter på återkallade portaler | En återkallad portal spärras, raderas inte; dess prenumeranter finns kvar tills arbetsytan raderas. | Ändamålet (att skicka rapporten) upphörde med återkallelsen. |
| Studielistor utan lagringstid | Efter publicering finns värdar och segment kvar; studier som aldrig publicerats behåller också sina rådata. | Löftet ”rådata raderas” gäller endast publicerade studier. |
| Interna kontroller utan raderingsväg | Kontroller med förtroendenivån ”intern” som varken har domän eller rapport (studier och kontroller som operatören skapat från kommandoraden) omfattas inte av någon raderingsväg; med dem finns formulär, fynd och skärmbilder av tredje parters webbplatser kvar. | Gäller principen om lagringsminimering (Art. 5(1)(e)); berör personer som inte vet något om kontrollen. Bedöms som hög risk i konsekvensbedömningen avseende dataskydd. |
| Bevis på kontroll förnyas inte | Bevis på kontroll kontrolleras en gång; det finns ingen väg i koden genom vilken en domän förlorar det igen. | Aktiva testinskickningar, filsökning och skanningen bakom inloggningen fortsätter efter ett byte av ägare eller uppdrag. |
| Skanning bakom inloggningen: transport till kundens sida | Som inloggningsadress tillåts http vid sidan av https, och certifikatfel på kundens sida stoppar inte inloggningen. | Inloggningsuppgifter för testkonton skulle kunna avlyssnas på vägen till kundens sida. |
| Radering är beroende av ett tidsfönster | Det dagliga blocket körs endast om en statuskörning startar mellan kl. 03:00 och 03:04. Om just denna körning misslyckas (databasen nås inte, servern startades om) blir det ingen radering och ingen säkerhetskopia den dagen; det finns ingen efterkörning. Vad som raderades loggas inte permanent. | Lagringstiderna förlängs då i tysthet med en dag. Ett missat fönster utlöser inget larm; endast en säkerhetskopiering som körs och misslyckas rapporteras. Konfigurationslistan i administrationsområdet visar datumet för den senaste lyckade säkerhetskopian. |
| Vissa raderingar är beroende av övervakningen | Tömning av leveranskontrollens kontrollbrevlåda, radering av incidenter, skickade sammanfattande aviseringar, svärmsignaler och kontroller av potentiella kunder samt rensning av kvarvarande testkontokopior i jobb körs i statuskörningens schemaläggningsdel, som bara fungerar medan övervakningen är påslagen i administrationsområdet; tilldelningarna i leveranskontrollen raderas endast medan en kontrollbrevlåda är konfigurerad. | Om övervakningen stängs av centralt eller brevlådan tas bort upphör dessa lagringstider att verka utan att någon märker det. |
| Kontaktpunkt och brevlådor utan lagringstid | Sårbarhetsrapporter och andra inkommande e-postmeddelanden förvaras utanför applikationen; ingen lagringstid har fastställts. | Rapporter kan innehålla bevis från tredje part. |
| Värden i dolda fält läses under kontrollen | Skannern läser värdet i dolda formulärfält upp till 24 tecken och dataattribut upp till 60 tecken för att känna igen tidsstämplar och token. Endast fältnamn, typ, etikett och igenkänningsresultatet går in i fältkartan och fynden, inte värdet. | Ingen lagringslucka; värdet finns endast i skanningscontainerns arbetsminne under kontrollen. Ett förifyllt värde (t.ex. ett kundnummer) läses därvid, men lagras inte. |
| Härledd avsändardomän i autentiseringsresultatet | A.1. | För besökares personliga domäner personuppgifter som härrör från ett verkligt meddelande. |
| Härdningen av serveradministrationen är inte slutförd; interna anslutningar inte genomgående krypterade | Avsnitt 8.1. Härdningen pågår; vi anger inga detaljer offentligt. | En säkerhetsincident på servernivå skulle drabba applikation, databas och säkerhetskopior samtidigt. |
| Mätning i utvecklingssystemet | Schema, kod och inställningar mättes i utvecklingssystemet. | Kod och schema överensstämmer med produktionssystemet; inställningar kan skilja sig och måste kontrolleras på nytt där före lanseringen. |
11. Underhåll av detta register
Art. 30 kräver att registret förs skriftligt och på begäran görs tillgängligt för tillsynsmyndigheten. Det kräver någon som ansvarar för det och ett intervall med vilket det kontrolleras mot systemet snarare än mot sin föregående version.
- Ansvar: Lukas Wójcik, ägare. Det granskas årligen och varje gång en behandling ändras.
- Händelser som kräver en uppdatering: ett nytt eller ändrat underbiträde, särskilt valet av e-postleverantör; en ny tabell eller ett nytt fält med personuppgifter; en ändring av lagringstiderna eller raderingskedjorna i
cfg/fristen_lib.php eller srv/cron_status.php; en ny larmkanal eller en ny förfrågan till en tredje part; påslagning av en funktion som är avstängd som standard (svärmskydd med IP-nät, sond, egna domäner, partnerprogram, betalning mot faktura, Spamhaus eller Google Web Risk); en flytt till andra servrar.
- Förfarande: varje uppgift här kommer från kod, schema eller mätning. En granskning som bara läser texten har inte granskat någonting: schema och raderingskedjor mäts på nytt, platshållare förblir platshållare, öppna punkter stängs eller förs vidare med motivering.
- Förhållande till andra dokument: detta register ersätter inte integritetspolicyn, personuppgiftsbiträdesavtalet, de tekniska och organisatoriska åtgärderna eller förteckningen över underbiträden. Där de och detta register skiljer sig åt är skillnaden ett fynd.
- Ändringar i detta dokument förtecknas på sidan Ändringar i avtalsdokumenten.