Registro delle attività di trattamento (art. 30 GDPR)

Il presente documento è pubblicato in più lingue. In caso di discrepanze tra le versioni linguistiche, fa fede la versione polacca.

Versione 1.2 · Ultimo aggiornamento: 29 ottobre 2026

1. Come leggere il presente registro

Questo è il registro delle attività di trattamento ai sensi dell'art. 30 GDPR per formexposed. Non è un'informativa sulla privacy e non è marketing. Il suo compito è mostrare a un'autorità di controllo, a un Cliente che ci sottopone ad audit in qualità di responsabile del trattamento o alla prossima persona che deve rispondere a una domanda che cosa viene effettivamente trattato, dove è conservato, chi lo riceve e per quanto tempo rimane. Lo pubblichiamo perché un servizio che verifica e monitora i moduli dovrebbe a sua volta essere aperto alle verifiche.

La sua redazione è stata guidata da tre regole.

1. Misurato, non previsto. Un'affermazione su campi di dati, periodi di conservazione, destinatari o garanzie compare solo laddove il codice del programma, lo schema del database o una misurazione la supportano. Ciò che è pianificato è definito “pianificato”. Ciò che è disattivato per impostazione predefinita è definito “disattivato per impostazione predefinita”. Laddove non possiamo dimostrare qualcosa, lo diciamo.
2. La conservazione è indicata due volte. Una volta per ciascuna attività di trattamento e una volta nella sezione 6 come quadro complessivo: quale processo notturno cancella quali dati e quali dati non raggiunge. Un registro che dichiara un periodo di conservazione valido solo per una parte dei dati è peggiore di uno che indica il punto aperto.
3. I punti aperti sono indicati nel testo, non in una nota a piè di pagina. La sezione 8.1 elenca le misure non ancora attuate, la sezione 10 i punti aperti con le misure pianificate. Un registro è uno strumento di lavoro, non un certificato.

Campi di dati anziché nomi di tabelle. Per ciascuna attività di trattamento elenchiamo i dati memorizzati come campi in linguaggio semplice. Il nome della tabella del database segue tra parentesi affinché un revisore possa trovarne la posizione, ad esempio “tentativi di login (login_attempts)”. Gli elenchi dei campi sono stati ricavati dallo schema del database, non dalla memoria.

Periodi di conservazione come segnaposto. Laddove un periodo di conservazione possa essere impostato nell'area di amministrazione, compare qui esattamente come lo legge il processo notturno: il numero che vede proviene dalla stessa impostazione che governa la cancellazione. I periodi di conservazione fissati nel programma sono indicati come numeri.

Base di misurazione. Schema, codice e impostazioni sono stati misurati l'11 ottobre 2026 sul sistema di sviluppo, che corrisponde al sistema di produzione per codice e schema. Non indichiamo il numero di righe del sistema di sviluppo; contengono dati di prova e non dicono nulla sull'esercizio reale.

Volutamente omesso. Il presente registro non indica nomi host, indirizzi di rete interni, porte, nomi utente né versioni software dei nostri server. Tali dettagli aiutano un aggressore e nessun interessato. Per lo stesso motivo descriviamo solo in termini generali i punti aperti nella messa in sicurezza dei nostri server (sezione 8.1): indichiamo il rischio, non la strada per arrivarci. Forniamo i dettagli a un'autorità di controllo su richiesta.

Natura giuridica. Il presente registro è la documentazione che teniamo ai sensi dell'art. 30 GDPR per l'autorità di controllo; è pubblicato volontariamente. Non costituisce parte di alcun contratto e non costituisce alcuna dichiarazione, garanzia o accordo sulla qualità nei confronti dei Clienti o di terzi. Ciò che dobbiamo ai Clienti è disciplinato dalle Condizioni di servizio, dall'Accordo sul trattamento dei dati e dai relativi allegati; con riguardo a tali obblighi, essi prevalgono sul presente registro. Il registro descrive la situazione alla data della presente versione. Classificazioni come “punto aperto” o “valutazione” riflettono il nostro punto di vista e non anticipano alcuna valutazione giuridica da parte di un'autorità di controllo o di un tribunale; le misure descritte come “pianificate” sono intenzioni senza una data vincolante.

2. Il soggetto giuridico e perché il presente registro ha due metà

Campo	Voce
Soggetto giuridico	LW IT Solutions Company Lukas Wójcik, impresa individuale iscritta nel registro delle imprese polacco (CEIDG); titolare Lukas Wójcik
Indirizzo	al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia
Identificativi fiscali	NIP 7252266190, partita IVA PL7252266190
Contatto	contact@lukaswojcik.com; la finestra di assistenza (punto interrogativo nella navigazione); la pagina dei contatti
Servizio	formexposed: verifica, monitoraggio e messa in sicurezza dei moduli di contatto sui siti web (app su formexposed.com, landing page su form.exposed)
Rappresentante ai sensi dell'art. 27 GDPR	Non applicabile. Il soggetto giuridico è stabilito nell'Unione (Polonia).
Responsabile della protezione dei dati	Non designato. La valutazione ai sensi dell'art. 37 si trova nella sezione 9.
Autorità di controllo competente	Prezes Urzędu Ochrony Danych Osobowych (UODO, l'autorità polacca per la protezione dei dati), ul. Moniuszki 1A, 00-014 Warszawa
Hosting	Server propri in Polonia: un server web con l'applicazione e il database e un server di scansione con un modello linguistico locale nella stessa rete interna. Nessun data center o fornitore cloud di terzi.

formexposed svolge ruoli diversi nei confronti di diversi gruppi di persone. Confonderli produce un registro che non è corretto per nessuno di essi.

• Titolare del trattamento (Parte B, art. 30(1)). Siamo noi stessi titolari del trattamento per i dati dei nostri Clienti e dei membri dei loro team (account, login, fatturazione, assistenza, log), per i visitatori del nostro sito web, per le verifiche senza account (verifica gratuita, strumento header, studio, verifica dei potenziali clienti) e per la prevenzione degli abusi.
• Responsabile del trattamento (Parte A, art. 30(2)). Per i dati personali di terzi che un Cliente introduce nel servizio o che sorgono quando eseguiamo un servizio per il Cliente, agiamo per conto del Cliente: copie di e-mail reali dei moduli nel controllo di recapito, iscritti al portale clienti del Cliente, destinatari degli avvisi del Cliente, persone casualmente visibili sulle pagine verificate del Cliente, le credenziali dell'account di prova del Cliente e il codice del modulo che il Cliente incolla. La base è l'Accordo sul trattamento dei dati, che viene concluso con ogni Cliente al momento della registrazione.
• Solo dal lato del Cliente. Alcune funzioni del plugin WordPress e dell'estensione TYPO3 trattano dati esclusivamente sul sito web del Cliente, senza che i dati ci raggiungano mai (quarantena, rete di sicurezza, quesito aritmetico, impostazioni di conservazione, contatori locali, registratore). Non costituiscono un trattamento da parte nostra e pertanto non compaiono in nessuna delle due parti. Le descriviamo comunque alla fine della Parte A affinché il confine sia visibile.

La separazione è integrata nel codice, non solo nel testo: di un'e-mail reale di un modulo, il controllo di recapito scrive nel database solo l'ora, l'assegnazione e il risultato dell'autenticazione; gli screenshot delle verifiche nel browser mascherano i campi di inserimento; le credenziali dell'account di prova sono cifrate in modo tale che il server web non possa più leggerle. I dettagli sono riportati nelle singole voci.

Le sezioni da 6 a 11 si applicano a entrambe le metà: conservazione, decisioni automatizzate, misure tecniche e organizzative, responsabile della protezione dei dati, punti aperti e aggiornamento del presente registro.

Ambito. Il presente documento è la parte del registro che riguarda il servizio formexposed. I trattamenti effettuati dallo stesso soggetto giuridico per altri servizi sono registrati nei rispettivi registri; la contabilità generale e l'amministrazione aziendale al di fuori del servizio non rientrano in questa parte.

3. Parte A – art. 30(2): trattamenti per conto dei Clienti

A.0 Soggetti coinvolti

Campo	Voce
Responsabile del trattamento	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia; contact@lukaswojcik.com
Titolari del trattamento	I Clienti di formexposed: imprese e agenzie che hanno domini nel proprio account e utilizzano funzioni in cui sorgono dati di terzi. Nel caso delle agenzie, può essere titolare del trattamento anche il cliente dell'agenzia stessa; l'agenzia agisce quindi come responsabile del trattamento nei confronti di tale cliente e noi come ulteriore responsabile.
Elenco dei titolari del trattamento	Parte del presente registro, tenuto in forma elettronica (art. 30(3) GDPR) nel sistema del servizio e non riprodotto in questa versione pubblica, perché contiene dati personali dei Clienti e sarebbe superato a ogni nuovo Cliente: il proprietario di ciascuna area di lavoro con nome, indirizzo e-mail e azienda dall'account cliente (indirizzo e partita IVA solo presso Stripe) (users, workspaces, workspace_users), oltre ai domini dell'area di lavoro (domains). Lo forniamo a un'autorità di controllo come estratto su richiesta.
Rappresentanti e responsabili della protezione dei dati dei titolari del trattamento	Nel sistema non esiste un campo dedicato a tal fine. Se un Cliente ha designato un rappresentante ai sensi dell'art. 27 GDPR o un responsabile della protezione dei dati, può comunicarceli; conserviamo la comunicazione insieme all'elenco dei titolari del trattamento.
Rappresentante del responsabile del trattamento	Non applicabile (stabilito in Polonia).
Responsabile della protezione dei dati	Non designato (sezione 9).
Istruzioni	L'istruzione deriva dall'Accordo sul trattamento dei dati e dalle impostazioni effettuate dal Cliente: il Cliente attiva il controllo di recapito, configura le destinazioni degli avvisi, memorizza un account di prova e configura un portale clienti. Senza tale azione il trattamento in questione non ha luogo.
Misure tecniche e organizzative	La sezione 8 e la pagina Misure tecniche e organizzative si applicano a ogni attività di trattamento della Parte A. Le misure particolari sono indicate nella voce pertinente.

A.1 Controllo di recapito – copia di controllo delle e-mail dei moduli

Campo	Voce
Finalità	Verificare se l'e-mail del modulo di contatto del Cliente viene effettivamente inviata e come viene autenticata (SPF, DKIM, DMARC, allineamento). Dopo un invio di prova attivo accettato, la relativa copia deve arrivare nella casella di controllo entro un tempo di attesa regolabile (attualmente 3 ore); altrimenti viene generato l'avviso “E-mail di prova non ricevuta”. Dagli header si ricavano inoltre l'autenticità dell'e-mail del modulo, il servizio e-mail utilizzato e l'indirizzo di invio per la verifica delle blocklist.
Presupposto	Piano a pagamento, dominio verificato, attivazione da parte del Cliente. Il Cliente inserisce come copia nascosta nella notifica del proprio modulo il proprio indirizzo di controllo con un identificativo (nella forma “delivery+identificativo@…”). Senza una casella di controllo configurata la funzione non è disponibile.
Categorie di interessati	Visitatori del sito web del Cliente che inviano il modulo del Cliente; persone i cui dati un visitatore scrive nel messaggio; personale del Cliente che compare come destinatario negli header.
Categorie di dati personali	Nella casella di controllo (presso il fornitore del servizio di posta): la copia completa di ogni e-mail del modulo, comprese le richieste reali con nome, indirizzo e-mail, numero di telefono e testo libero, fino alla cancellazione. Letti dal recupero: gli header e al massimo i primi 8 KB del corpo. Nel database: ora di ricezione, assegnazione al dominio e, se del caso, all'esecuzione di prova (delivery_log); il risultato di autenticazione più recente per dominio con esito SPF, DKIM e DMARC, allineamento, dominio del mittente, domini di firma e indirizzo del server di posta mittente (campo di autenticazione del dominio in domains). Il contenuto, l'oggetto e l'indirizzo del mittente del visitatore non vengono scritti nel database.
Nota sul dominio del mittente	Se un modulo inserisce come mittente l'indirizzo del visitatore (un errore di configurazione che la verifica è progettata a scoprire), il risultato dell'autenticazione contiene il dominio di tale indirizzo, non l'indirizzo stesso. Se un visitatore utilizza un dominio personale, anche questo può costituire un dato personale. Viene sovrascritto alla ricezione successiva.
Fonte	Il modulo sul sito web del Cliente, tramite la copia nascosta inserita dal Cliente.
Base giuridica (determinata dal titolare del trattamento)	Determinata dal Cliente. Il nostro testo suggerito per l'informativa sulla privacy del Cliente basa la copia sull'art. 6(1)(f) GDPR (legittimo interesse a ricevere le richieste in modo affidabile). Il Cliente informa i propri visitatori di questo flusso di dati; l'Accordo sul trattamento dei dati lo obbliga a farlo.
Destinatari	Il fornitore del servizio di posta che gestisce la casella di controllo (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). La copia giunge direttamente lì: arriva solo se i record MX del nostro dominio puntano a questa casella (la checklist pre-lancio lo verifica); tramite un inoltro non raggiunge la casella. Nella pagina del dominio il Cliente vede solo ora, assegnazione e risultato dell'autenticazione. Se il risultato dell'autenticazione peggiora, l'avviso al Cliente e ai canali da lui scelti indica il dominio del mittente se non appartiene al sito web (A.3, 4.1).
Paese terzo	Dipende dal fornitore del servizio di posta; vedi sezione 4. Il contratto con il fornitore previsto e la base per il trasferimento non sono ancora documentati.
Conservazione	Dopo l'elaborazione riuscita, l'e-mail viene contrassegnata per la cancellazione e rimossa dalla casella nella stessa esecuzione, anche se non può essere assegnata ad alcun dominio. Il recupero viene eseguito con il processo di stato ogni cinque minuti mentre il monitoraggio è attivato nell'area di amministrazione (srv/cron_status.php, cfg/zustellung_lib.php). Se il recupero o la cancellazione non riescono, l'e-mail resta nella casella fino al successivo recupero riuscito. Lo stesso recupero cancella le assegnazioni in delivery_log dopo 180 giorni. Il risultato dell'autenticazione dura quanto il dominio.
Che cosa dimostra la prova	Solo la ricezione, nella casella di controllo, della copia assegnata alla specifica esecuzione di prova. Non dimostra né la ricezione da parte del destinatario effettivo né l'inserimento nel CRM. Non è offerta una conferma nativa da HubSpot.
TOM	Sezione 8. In particolare: il contenuto viene valutato solo in memoria; nessuna memorizzazione di corpo, oggetto o indirizzi completi del mittente; cancellazione indipendentemente dalla riuscita dell'assegnazione.

Il controllo di recapito è l'unica funzione tramite la quale ci raggiungono messaggi reali dei visitatori dei nostri Clienti. Per questo costituisce un trattamento per conto del Cliente e non un servizio sotto la nostra responsabilità, e per questo il tempo trascorso nella casella di posta è la vera misura del rischio: normalmente minuti; se il recupero è disturbato, fino alla sua successiva esecuzione. Le copie non dovrebbero contenere categorie particolari di dati personali; non possiamo impedirlo tecnicamente, perché ciò che un visitatore scrive dipende dal visitatore.

A.2 Portale clienti e report mensile agli iscritti

Campo	Voce
Finalità	Un'agenzia (piano Business) mostra ai propri clienti lo stato dei loro domini con il proprio marchio (portale a un indirizzo casuale, facoltativamente con password, facoltativamente sotto un sottodominio proprio dell'agenzia). Lì il cliente può ordinare un report mensile via e-mail. Il report viene inviato a nome dell'agenzia.
Categorie di interessati	I clienti dell'agenzia e il loro personale che ordinano il report; persone che aprono il portale.
Categorie di dati personali	Iscritto: indirizzo e-mail, lingua, identificativo di conferma, ora dell'ordine e indirizzo IP al momento dell'ordine, ora della conferma (double opt-in), ora della cancellazione dell'iscrizione, ultimo mese inviato (client_subscribers). Portale: nome, selezione dei domini, identificativo casuale, password solo come hash, persona che lo ha creato, ora, revoca (client_portals). Le visite al portale compaiono nel registro delle visualizzazioni di pagina (B.2).
Fonte	Inseriti dagli iscritti stessi nel portale.
Base giuridica (determinata dal titolare del trattamento)	Il consenso dell'iscritto, ottenuto tramite una procedura di double opt-in; il titolare del trattamento è l'agenzia. Non scriviamo a nessuno che non si sia iscritto e non abbia confermato personalmente.
Destinatari	L'agenzia (vede i propri iscritti); il fornitore del servizio di posta (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) per l'e-mail di conferma e il report.
Paese terzo	Tramite il fornitore del servizio di posta; vedi sezione 4.
Conservazione	Processo di cancellazione notturno (cfg/fristen_lib.php, parte “iscritti ai portali”): ordini mai confermati dopo 30 giorni; iscritti che hanno annullato l'iscrizione tre anni dopo la cancellazione, come prova del precedente consenso. Gli iscritti confermati che non hanno annullato l'iscrizione restano finché esiste l'area di lavoro dell'agenzia. Un portale revocato viene solo bloccato, non cancellato; i suoi iscritti non ricevono più report, ma i loro dati restano (sezione 10). Portali e iscritti vengono eliminati immediatamente con l'area di lavoro (fe_arbeitsbereich_daten_loeschen()). I report inviati restano nella posta in uscita per 30 giorni (B.25).
TOM	Sezione 8. In particolare: password del portale solo come hash, tentativi di indovinarla limitati (dieci per portale e indirizzo IP, 50 per portale in 15 minuti); cancellazione dell'iscrizione con un clic in ogni e-mail; il portale mostra solo lo stato e i dati principali, nessun singolo risultato con prove.

A.3 Destinatari degli avvisi, persone che prendono in carico e responsabili assegnati del Cliente

Campo	Voce
Finalità	Notifiche su guasti e modifiche alle destinazioni che il Cliente configura per un dominio: e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Per destinazione immediatamente oppure raccolte giornalmente o settimanalmente, più destinazioni solo per le escalation. Ogni notifica di problema diventa un incidente, che il destinatario può prendere in carico tramite un link. Per i moduli monitorati, il Cliente può indicare una persona responsabile e una scadenza.
Categorie di interessati	Personale e fornitori di servizi del Cliente che il Cliente inserisce come destinazione degli avvisi o indica come responsabili assegnati; persone che prendono in carico un incidente. I membri del team con un proprio account compaiono anche nella Parte B.
Categorie di dati personali	Destinazione degli avvisi: canale, indirizzo di destinazione (indirizzo e-mail, indirizzo webhook o chat, ID chat Telegram), eventi selezionati, modalità di recapito, segreto di firma per i webhook, ultimo recapito e ultimo errore (alerts). Registro dei recapiti: destinazione, eventi, stato, errore, ora (alert_log). Coda dei riepiloghi: righe di notifica e link fino al recapito (alert_queue). Incidente: titolo, righe di notifica, link, identificativo di presa in carico, ora e nome o indirizzo e-mail della persona che prende in carico come inserito nel modulo, altrimenti l'indirizzo del membro connesso (alert_incidents). Tentativi di recapito dell'escalation per incidente e destinazione: numero di tentativi (al massimo cinque), orari dell'ultimo e del prossimo tentativo e della riuscita, riferimento all'e-mail nella posta in uscita, errore (tabella alert_escalation_deliveries). Assegnazione: account della persona responsabile e scadenza (in monitored_forms).
Contenuto delle notifiche	Dominio, evento, una breve spiegazione e un link alla pagina del dominio. Nessun contenuto dei messaggi dei visitatori.
Fonte	Inseriti dal Cliente; la persona che prende in carico inserisce essa stessa il proprio nome; l'ID chat Telegram viene creato quando il destinatario preme “Start” nel bot (B.32).
Base giuridica (determinata dal titolare del trattamento)	Determinata dal Cliente; di norma l'organizzazione della propria attività da parte del Cliente (art. 6(1)(b) o (f) GDPR in relazione al personale e ai fornitori di servizi del Cliente).
Destinatari	I gestori dei canali scelti; vedi 4.1. Avvisi via e-mail tramite il fornitore del servizio di posta (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Paese terzo	A seconda del canale scelto; diversi fornitori hanno sede negli USA, Telegram al di fuori dell'UE senza decisione di adeguatezza. Vedi 4.1.
Conservazione	Registro dei recapiti dopo 90 giorni (ogni notte, fe_alert_log_aufraeumen() da srv/cron_status.php). Notifiche dei riepiloghi 30 giorni dopo il recapito (cfg/kanal_lib.php, a ogni recapito di riepilogo). Incidenti finché non risolti; quelli risolti 180 giorni dopo la risoluzione (cfg/vorfall_lib.php, processo di escalation), insieme ai relativi tentativi di recapito dell'escalation. Destinazioni degli avvisi e assegnazioni fino alla cancellazione da parte del Cliente o insieme al dominio.
TOM	Sezione 8. In particolare: webhook firmati con un segreto separato per destinazione; presa in carico solo dopo un clic (POST), affinché le anteprime dei link nei programmi di chat non attivino nulla; gli avvisi durante una finestra di manutenzione vengono solo registrati, non inviati.

A.4 Persone casualmente visibili sulle pagine verificate del Cliente e negli screenshot

Campo	Voce
Finalità	La verifica dei domini nell'account del Cliente (scansione, monitoraggio, verifica attiva) legge le pagine pubbliche del Cliente e acquisisce screenshot dei moduli. Ciò che la pagina stessa mostra può riguardare persone che non hanno nulla a che fare con la verifica. Questi dati sorgono incidentalmente; non sono la finalità della verifica.
Categorie di interessati	Persone il cui nome, foto o recapiti compaiono sulla pagina verificata (referente accanto al modulo, foto del team sulla home page, dati delle note legali).
Categorie di dati personali	Screenshot: l'area visibile della home page, ogni modulo visibile come ritaglio e l'immagine della pagina successiva dopo un invio di prova attivo; memorizzati come file al di fuori della directory web, con solo il riferimento nel database (scan_screenshots). Struttura del modulo: indirizzo della pagina, selettore, nomi dei campi, tipi di campo, etichette dei campi, indicatori di obbligatorietà e visibilità, etichette dei pulsanti di invio (forms, campo “mappa dei campi”); nessun valore dei campi. Lo scanner legge l'inizio dei campi nascosti (fino a 24 caratteri) e degli attributi data (fino a 60 caratteri) solo durante la verifica, per riconoscere marche temporali e token; viene memorizzato solo il risultato. Risultati con prove (findings), riepilogo con titoli delle pagine (scans). Se nel modulo compare un indirizzo e-mail come destinatario, ne viene memorizzato solo il dominio, mai l'indirizzo.
Fonte	Le pagine pubbliche del dominio del Cliente, recuperate dallo scanner.
Base giuridica (determinata dal titolare del trattamento)	Determinata dal Cliente per il contenuto del proprio sito web. Per noi il trattamento fa parte della verifica commissionata.
Destinatari	Il Cliente; nel caso delle agenzie, il loro cliente tramite il portale o un report white label; chiunque riceva un link a un report (report a indirizzi casuali, non nei motori di ricerca). Laddove il tipo di modulo non sia chiaro, un modello linguistico locale sul nostro server riceve per la classificazione la struttura del modulo con titolo della pagina, indirizzo della pagina e testo visibile del modulo (fino a 400 caratteri); non riceve immagini.
Paese terzo	Nessuno.
Conservazione	Risultati delle verifiche per un dominio per al massimo 13 mesi; l'ultima verifica completata per dominio resta (processo di cancellazione notturno, parte “vecchi risultati delle verifiche”). Moduli, risultati, riferimenti alle immagini e i file immagine seguono il risultato della verifica. Con il dominio questi dati vengono eliminati immediatamente (catena di cancellazione in B.15; eccezioni nella sezione 6.4).
Limiti del mascheramento	Gli screenshot della verifica completa non mascherano nulla: mostrano ciò che la pagina mostra a ogni visitatore. I campi del modulo sono vuoti al momento del recupero, perché lo scanner non inserisce nulla; i valori precompilati sarebbero visibili. Dietro un login non vengono acquisiti screenshot (A.5). Le immagini delle verifiche nel browser mascherano i campi di inserimento (A.6).
TOM	Sezione 8. In particolare: le immagini possono essere recuperate solo tramite il report, e l'identificativo di un'immagine altrui restituisce “non trovato”; report con noindex; ogni verifica viene eseguita in un proprio container isolato.

Gli stessi dati sorgono nelle verifiche senza account (verifica gratuita, studio, verifica dei potenziali clienti). Lì non c'è alcun Cliente per conto del quale agiamo; questi casi compaiono quindi nella Parte B (B.5, B.7, B.8).

A.5 Credenziali dell'account di prova per la scansione dietro il login

Campo	Voce
Finalità	Lettura dei moduli che compaiono solo dopo il login (area clienti, area riservata ai membri). Lo scanner accede con un account di prova che il Cliente ha creato sul proprio sito web e legge le pagine indicate. A parte il modulo di login non invia nulla, non vi esegue alcun test attivo, non acquisisce screenshot e non visita indirizzi di logout, cancellazione o disdetta. Se il modulo di login ha un CAPTCHA, si ferma; i CAPTCHA non vengono aggirati.
Presupposto	Dominio verificato, piano a pagamento, ruolo di proprietario o amministratore, conferma espressa che l'account è un account di prova. Al massimo cinque pagine, tutte sullo stesso dominio.
Categorie di interessati	La persona a nome della quale è intestato l'account di prova (idealmente nessuno; il Cliente dovrebbe utilizzare un account funzionale); persone i cui dati compaiono nelle pagine dietro il login.
Categorie di dati personali	Nome utente e password dell'account di prova, solo in forma cifrata; un'indicazione del nome utente (primo carattere e lunghezza); indirizzo di login, elenco delle pagine, nomi dei campi di login, indicatore di riuscita, persona che lo ha creato, orari, ultimo risultato come codice breve (domain_logins). Per un lavoro in esecuzione, una copia del testo cifrato (campo “pacchetto di login” in scan_jobs). Dalle pagine dietro il login: struttura del modulo come in A.4, senza screenshot e senza cookie.
Fonte	Inseriti dal Cliente nell'account.
Base giuridica (determinata dal titolare del trattamento)	Determinata dal Cliente. Il Cliente garantisce di essere autorizzato a utilizzare l'account di prova.
Destinatari	Nessuno. Né il Cliente né l'assistenza né l'interfaccia di programmazione possono leggere le credenziali; l'interfaccia mostra solo l'indicazione del nome utente.
Paese terzo	Nessuno.
Protezione delle credenziali	Nome utente e password vengono cifrati immediatamente al momento della memorizzazione con la chiave pubblica del server di scansione (X25519, HKDF-SHA256, AES-256-GCM; il dominio è vincolato come dato associato, quindi un testo cifrato non può essere collegato a un altro dominio). Solo il server di scansione possiede la chiave privata. Server web, database e backup contengono solo testo cifrato; neppure noi possiamo decifrarlo lì. Il server di scansione decifra solo per l'esecuzione, passa le credenziali al container di verifica isolato solo tramite lo standard input, cancella immediatamente la copia nel lavoro e non la scrive in alcun risultato, log o testo di errore. Nel tragitto verso il sito web del Cliente sono protette solo dalla cifratura di tale sito web; i limiti di questo trasporto sono illustrati nella sezione 10.
Conservazione	Credenziali memorizzate fino alla cancellazione da parte del Cliente. Alla cancellazione, il testo cifrato viene sovrascritto con dati casuali della stessa lunghezza e la riga viene cancellata; i lavori in attesa vengono svuotati (fe_login_loeschen()). Con il dominio la riga viene eliminata tramite una chiave esterna. Il server di scansione elimina le copie nei lavori dopo l'esecuzione; eventuali residui (lavoro interrotto, server di scansione non disponibile) vengono eliminati dal processo di stato al più tardi dopo un'ora (fe_login_aufraeumen(), parte “login_jobs”). I backup del database contengono il testo cifrato fino alla scadenza del backup dopo 14 giorni.
TOM	Sezione 8. In particolare: cifratura asimmetrica con chiavi separate; blocklist per i percorsi di logout e cancellazione; nessuno screenshot dietro il login; funzione solo per piani a pagamento e domini verificati; ogni modifica nel registro delle attività (senza credenziali).

Non abbiamo volutamente previsto alcuna possibilità di memorizzare credenziali per il server del Cliente, l'area di amministrazione del CMS o gli account di hosting. L'account di prova è un account visitatore sul sito web del Cliente, non un accesso al sistema del Cliente.

A.6 Percorsi dei moduli configurati, verifiche nel browser e sonda indipendente

Campo	Voce
Finalità	Un modulo monitorato viene percorso in un browser reale (Chromium, WebKit o entrambi) fino al momento immediatamente precedente l'invio: caricare la pagina, eseguire i clic preliminari (al massimo cinque, mai su un campo di inserimento o su un pulsante di invio), compilare i campi con valori riconoscibilmente sintetici (come un indirizzo con la desinenza riservata .invalid), avanzare nei moduli a più passaggi. La verifica nel browser non invia nulla; l'invio è tecnicamente bloccato nel browser. Inoltre misurazioni dei tempi e confronti visivi del modulo.
Categorie di interessati	Come A.4 (persone visibili sulla pagina del modulo); il personale del Cliente indicato come responsabile assegnato (A.3).
Categorie di dati personali	Configurazione: indirizzo del modulo, selettori, indirizzo di ingresso, passaggi di clic, scelta del browser, etichetta, criticità, assegnazione, scadenza (monitored_forms). Risultati per esecuzione: stato, motivo tecnico dell'errore, messaggi di errore ripuliti, misurazioni di rete e dei tempi, un'immagine del modulo come JPEG di al massimo 32 KB con campi di inserimento mascherati (form_browser_runs). Osservazioni per verifica (form_observations), serie temporali (form_performance). Lavori con un elenco di destinazioni (campi “targets” e “result” in scan_jobs).
Accesso di prova	Se il Cliente ha memorizzato un account di prova (A.5), la verifica completa lo utilizza anche per i percorsi dei moduli configurati. Secondo il codice misurato, le verifiche nel browser autonome tra due verifiche complete funzionano senza account di prova.
Sonda indipendente	È previsto un secondo punto di controllo in un'altra sede, che effettuerebbe un controllo incrociato prima di un avviso. Riceverebbe il dominio, la configurazione ripulita e l'identificativo del lavoro, nessun inserimento dei visitatori e nessuna credenziale. Attualmente non è configurato (disattivato per impostazione predefinita). Senza la sonda non vi è prova da una seconda sede; un avviso si basa quindi sulla nostra misurazione.
Fonte	Configurati dal Cliente; risultati derivanti dal recupero della pagina del Cliente.
Base giuridica (determinata dal titolare del trattamento)	Determinata dal Cliente per il contenuto del proprio sito web e per le responsabilità del proprio personale.
Destinatari	Il Cliente; laddove sia configurata una sonda, il suo gestore (attualmente nessuno).
Paese terzo	Nessuno.
Conservazione	Risultati delle esecuzioni nel browser, lavori nel browser completati e serie temporali dopo 13 mesi (processo di cancellazione notturno, parti “browser_runs”, “browser_jobs”, “form_performance”). Configurazioni fino alla cancellazione del dominio (singolarmente possono essere modificate o disattivate, non cancellate); con il dominio vengono eliminate, insieme a esecuzioni, osservazioni e serie temporali, tramite chiavi esterne.
Che cosa dimostra la misurazione	Tempi e stati del nostro browser di verifica. Non misurano ciò che vivono i visitatori reali e non dimostrano né tassi di completamento né richieste perse.
TOM	Sezione 8. In particolare: invio tecnicamente impedito; solo indirizzi sullo stesso dominio; immagini mascherate; container di verifica isolato.

A.7 “Fix it for me” – codice del modulo incollato

Campo	Voce
Finalità	Il Cliente incolla il codice del proprio modulo; un modello linguistico sul nostro hardware vi integra il modulo di protezione. Viene restituito il file modificato, una patch, il risultato di un controllo della sintassi e un'indicazione se la chiamata di verifica è stata effettivamente integrata. Senza codice incollato, il servizio fornisce un modulo pronto con i nomi dei campi dell'ultima scansione.
Categorie di interessati	Persone i cui dati si trovano casualmente nel codice incollato (come un indirizzo del destinatario, nomi nei commenti, credenziali per un server di posta).
Categorie di dati personali	Il codice incollato, al massimo 30.000 caratteri. Nel database solo una voce nel registro delle attività (azione “fix_ai” con area di lavoro e ora), che viene conteggiata ai fini del limite giornaliero di attualmente dieci chiamate per area di lavoro.
Fonte	Incollato dal Cliente.
Base giuridica	Esecuzione del contratto con il Cliente (art. 6(1)(b) GDPR) per il codice stesso; per i dati di terzi casualmente contenuti in esso, la base è determinata dal Cliente.
Destinatari	Nessuno. Il modello linguistico funziona sul nostro server di scansione nella rete interna; nessun servizio di IA esterno, neppure come ripiego.
Paese terzo	Nessuno.
Conservazione	Il codice non viene memorizzato. Per il controllo della sintassi viene creato un file temporaneo, cancellato subito dopo. La voce nel registro delle attività viene cancellata dopo 365 giorni.
Nota per il Cliente	Il codice contenente password, chiavi API o dati personali dovrebbe essere ripulito prima di essere incollato. Non verifichiamo il contenuto.
TOM	Sezione 8. In particolare: solo proprietari e amministratori nei piani a pagamento; il codice incollato viene passato al modello contrassegnato come dati e non viene mai eseguito; nessun caricamento su server di terzi.

A.8 Marchio white label e referenti dell'agenzia

Campo	Voce
Finalità	I report, i report sintetici, i log probatori e il portale clienti di un'agenzia (piano Business) compaiono con il suo marchio, su richiesta sotto un sottodominio proprio dell'agenzia.
Categorie di interessati	Referenti dell'agenzia il cui nome o i cui recapiti compaiono nella riga di contatto.
Categorie di dati personali	Ragione sociale, sito web, riga di contatto, nota per il cliente, colore d'accento, aspetto, file del logo, interruttore per il riferimento a formexposed, dominio proprio con identificativo di verifica e stato della verifica (workspace_branding).
Fonte	Inseriti dall'agenzia.
Base giuridica	Esecuzione del contratto con l'agenzia (art. 6(1)(b) GDPR). Laddove la riga di contatto indichi personale dell'agenzia, la base è determinata dall'agenzia.
Destinatari	Chiunque riceva dall'agenzia un report, un report sintetico o un link al portale.
Paese terzo	Nessuno.
Conservazione	Fino alla modifica da parte dell'agenzia; marchio e file del logo vengono eliminati con l'area di lavoro (fe_arbeitsbereich_daten_loeschen()). Un dominio proprio la cui verifica DNS non riesce per sette giorni viene disattivato. Il dominio proprio è disattivato per impostazione predefinita.
TOM	Sezione 8.

A.9 Conteggi, indicatori di stato ed errori dei campi dal plugin e dall'estensione

Campo	Voce
Finalità	Una volta al giorno il plugin WordPress e l'estensione TYPO3 comunicano dati numerici sui moduli del sito web collegato: invii bloccati per motivo, invii, e-mail inviate e non riuscite, indicatori di stato delle impostazioni dei moduli, richieste memorizzate per fonte e periodo di conservazione. Facoltativi, disattivati per impostazione predefinita: eventi dei moduli e categorie di errore dei campi per posizione del campo. Da questi dati derivano “Protezione in cifre”, il report mensile, l'avviso di silenzio e le segnalazioni su impostazioni rischiose.
Classificazione	I dati numerici sono concepiti in modo da non descrivere alcuna persona. Li elenchiamo nella Parte A perché derivano da eventi sul sito web del Cliente generati dai visitatori del Cliente; a nostro avviso costituiscono dati personali al massimo in casi limite (un sito web con pochissimi invii in un dato giorno). La trasmissione stessa (chiavi, versioni, host) si trova nella Parte B (B.20).
Categorie di interessati	Visitatori del sito web del Cliente che inviano un modulo.
Categorie di dati personali	Dati giornalieri per host: bloccati in totale e per motivo, invii, e-mail inviate e non riuscite, categoria di errore dell'invio e-mail (solo una di quattro categorie, mai il testo dell'errore, perché può contenere indirizzi dei destinatari), conteggi delle risposte reCAPTCHA, richieste cancellate e rilasciate (plugin_stats). Stato: versioni da un elenco fisso di plugin per moduli, CAPTCHA e posta, indicatori delle impostazioni come numeri, periodi di conservazione (plugin_health). Notifiche di modifica: nome e versione di un plugin aggiornato (plugin_changes). Facoltativi: contatori per modulo e giorno con categorie di errore per posizione del campo (form_metrics). Mai: inserimenti, nomi dei campi, password, file, indirizzi e-mail, nomi, indirizzi IP o identificativi persistenti dei visitatori.
Fonte	Il plugin sul sito web del Cliente, tramite un'interfaccia di programmazione che utilizza il segreto di collegamento del sito web.
Base giuridica (determinata dal titolare del trattamento)	Determinata dal Cliente; il Cliente decide se attivare i conteggi facoltativi e come informare i propri visitatori.
Destinatari	Il Cliente. I domini dei link contenuti nei messaggi bloccati confluiscono nella protezione collettiva (B.21).
Paese terzo	Nessuno.
Conservazione	Dati giornalieri, notifiche di modifica e contatori dei moduli dopo 13 mesi (processo di cancellazione notturno, parti “plugin_stats” e “form_metrics”). Gli indicatori di stato vengono sovrascritti a ogni comunicazione. Tutti i dati del plugin per un host vengono eliminati non appena nessun dominio nel sistema fa più riferimento a tale host (immediatamente alla cancellazione dell'ultimo dominio; dati pregressi ogni notte, parte “orphan_hosts”).
Che cosa dimostrano i dati	Ciò che il plugin ha conteggiato. Non dimostrano né tassi di completamento né richieste perse.
TOM	Sezione 8. In particolare: accettazione solo con la coppia di chiavi vincolata del sito web; vengono accettate solo chiavi e numeri noti, tutto il resto viene scartato; i giorni al di fuori di una finestra di 14 giorni vengono rifiutati.

A.10 Confine: ciò che resta solo sul sito web del Cliente

Le seguenti funzioni del plugin WordPress e dell'estensione TYPO3 trattano dati esclusivamente sul server del Cliente. Non ci raggiungono e non vi abbiamo accesso. Ne è responsabile esclusivamente il gestore del sito web, che decide sull'attivazione, sui periodi di conservazione e su come informare i propri visitatori. A tal fine il plugin suggerisce paragrafi per l'informativa sulla privacy del gestore.

Funzione	Che cosa viene trattato localmente	Conservazione dal lato del Cliente
Quarantena	Invii bloccati con motivo, rilasciabili tramite e-mail all'indirizzo del sito web	14 giorni
Rete di sicurezza	Invii la cui e-mail del modulo non è riuscita, per il reinvio (attivata per impostazione predefinita)	30 giorni
Quesito aritmetico al posto di reCAPTCHA	Operazione aritmetica nel browser del visitatore, nessun servizio di terzi (disattivato per impostazione predefinita)	–
Impostazioni di conservazione	Cancellazione delle richieste memorizzate nei plugin per moduli dopo il periodo scelto dal gestore (disattivata per impostazione predefinita)	come configurato
Limitazione della frequenza	un identificativo di breve durata ricavato dall'indirizzo IP, non trasmesso a noi	di breve durata
Contatori giornalieri locali	Valori dei contatori prima della trasmissione	al massimo 14 giorni
Registratore per gli amministratori	selettori tecnici e passaggi di navigazione nel session storage del browser di un amministratore connesso; gli inserimenti non vengono letti. Viene trasmessa solo la configurazione selezionata (poi A.6)	al massimo 15 minuti
Aiuto per i visitatori	attivabile separatamente; non memorizza bozze e non reinvia automaticamente	–
Osservazione di nuove regole antispam	i riscontri aggiuntivi vengono conteggiati localmente, senza attivazione automatica	sette giorni

A.11 Protezione dei moduli (formconfirmed)

Campo	Contenuto
Finalità	Valutazione degli invii tramite moduli sui siti web del Cliente per riconoscere gli invii automatizzati: emissione e verifica di compiti (prova di lavoro), token di verifica monouso, tempo di compilazione, campo trappola, richieste ripetute; su richiesta del Cliente, valutazione del testo del messaggio da parte di un modello linguistico. Solo per i Clienti che attivano la protezione dei moduli.
Categorie di interessati	Visitatori dei siti web del Cliente che aprono una pagina con un modulo protetto o lo inviano.
Categorie di dati personali	Indirizzo IP (memorizzato solo in forma abbreviata e sottoposto a hash con una chiave che cambia ogni giorno), indirizzo e dominio della pagina, orari e tempo di compilazione, campo trappola compilato sì/no, identificativo del browser nel log del server web; solo con il controllo dei contenuti attivato, il testo del messaggio (solo nella memoria di lavoro).
Origine	Browser del visitatore (compito, token di verifica); server del Cliente (richiesta di verifica, eventualmente testo).
Destinatari	Il Cliente (punteggio, azione, motivi). Nessun altro; nessun sub-responsabile del trattamento per questo trattamento.
Paese terzo	Nessuno.
Conservazione	Identificativo sottoposto a hash 1 ora; token di verifica utilizzati al massimo 11 minuti; risultati delle verifiche senza indirizzo IP e senza testo 30 giorni; dati giornalieri 400 giorni; log del server web 14 giorni; testo nessuna conservazione.
Misure tecniche e organizzative	Sezione 8; inoltre abbreviazione e hash con chiave giornaliera, compiti firmati, utilizzo unico, modello linguistico su hardware di nostra proprietà senza registrazione del testo nei log.

4. Parte A – destinatari, sub-responsabili e trasferimenti verso paesi terzi

La tabella seguente elenca i destinatari di cui ci avvaliamo direttamente e che possono ricevere dati della Parte A. L'elenco di riferimento, costantemente aggiornato, è la pagina Sub-responsabili del trattamento; se differisce da questa tabella, si tratta di un rilievo, non di una questione di formattazione.

Destinatario	Che cosa riceve	Paese terzo	Base	Stato
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Casella di controllo del controllo di recapito (A.1); invio delle e-mail di avviso (A.3), delle conferme e dei report agli iscritti ai portali (A.2)	Luogo del trattamento ancora da verificare; vedi la pagina “Sub-responsabili del trattamento”	Accordo sul trattamento dei dati; base per il trasferimento ancora da verificare	Aperto. Il contratto pertinente, i luoghi effettivi del trattamento e la base per il trasferimento non sono ancora documentati. Il presente registro non conferma né una certificazione né un contratto concluso.
Namecheap, Inc. (registrar, DNS; inoltro delle e-mail fino alla configurazione della casella di posta)	Fino alla configurazione della casella di posta, la posta in arrivo generica agli indirizzi del nostro dominio; non le copie del controllo di recapito, che arrivano solo con record MX che puntano direttamente alla casella (A.1)	USA	da verificare: certificazione nell'ambito dell'EU-US Data Privacy Framework o clausole contrattuali tipo	In uso; base aperta.
Il nostro server di scansione con un modello linguistico locale	Struttura del modulo per la classificazione (A.4), codice incollato (A.7), accesso di prova decifrato solo durante l'esecuzione (A.5)	–	Gestito da noi, non un terzo	In uso.
Sonda indipendente in una seconda sede	Dominio, configurazione ripulita, identificativo del lavoro (A.6)	a seconda della sede	da determinare prima della messa in servizio	Non configurata.

Hosting: nessun terzo. Applicazione, database, screenshot e backup sono conservati sui nostri server in Polonia. Se passiamo a un data center o a un fornitore cloud, questo paragrafo deve essere riscritto.

4.1 Canali di avviso scelti dal Cliente

Oltre ai destinatari di cui ci avvaliamo, esistono canali che il Cliente sceglie per i propri avvisi (A.3). Il nostro server avvia la trasmissione; il Cliente determina la destinazione e il fornitore. La scelta di un canale non ci esonera dai nostri obblighi in qualità di responsabile del trattamento. Ruolo, contratto e garanzie necessarie per i paesi terzi devono essere determinati per ciascun fornitore; per i servizi di chat ciò non è ancora stato completato (questione aperta per la revisione legale).

Canale	Che cosa viene inviato	Sede del fornitore
E-mail	Dominio, evento, spiegazione, link; all'indirizzo inserito	tramite Namecheap, Inc. (Private Email), Phoenix, Arizona, USA
Webhook verso un indirizzo scelto liberamente	Evento in formato JSON (dominio, eventi, righe, link, marca temporale), firmato con il segreto della destinazione	determinata dal Cliente
Slack, Discord, Microsoft Teams, Google Chat	la stessa notifica come messaggio di chat all'indirizzo webhook inserito	prevalentemente USA
Telegram	destinazione scelta dal Cliente; inviamo il messaggio tramite il nostro bot all'ID chat collegato	al di fuori dell'UE, nessuna decisione di adeguatezza; la base per il trasferimento è una questione aperta per la revisione legale

In nessun caso viene inviato il contenuto di un messaggio di un visitatore. Le notifiche riportano dominio, evento e link.

5. Parte B – art. 30(1): trattamenti sotto la nostra responsabilità

Titolare del trattamento per tutto quanto contenuto in questa parte: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia, contact@lukaswojcik.com. Nessun rappresentante richiesto (stabilito nell'Unione). Nessun responsabile della protezione dei dati designato (sezione 9). Misure tecniche e organizzative: sezione 8 e la pagina Misure tecniche e organizzative. Il modo in cui gli interessati esercitano i propri diritti è descritto nella pagina Accesso, cancellazione e altri Suoi diritti; i titolari di account possono scaricare autonomamente i propri dati come file (Impostazioni).

Laddove ci basiamo sul legittimo interesse (art. 6(1)(f) GDPR), indichiamo l'interesse e il motivo per cui un mezzo meno invasivo non è sufficiente. Il bilanciamento è una nostra valutazione; è oggetto della revisione legale.

B.1 Visitatori del nostro sito web – log del server web

Campo	Voce
Finalità	Funzionamento e sicurezza del sito web e dell'app: consegna, risoluzione dei problemi, rilevamento di attacchi e sovraccarichi.
Categorie di interessati	Chiunque apra una pagina di formexposed.com o form.exposed, compresi i visitatori di pagine dei Clienti il cui browser carica la nostra immagine del badge (B.18), i destinatari che aprono un link a un report o di presa in carico e i siti web il cui plugin richiama la nostra interfaccia.
Categorie di dati personali	Indirizzo IP completo, ora, indirizzo richiesto, codice di stato, byte trasferiti, pagina di provenienza (referrer), identificativo del browser (user agent).
Luogo di conservazione	Log degli accessi del proxy a monte e del server web come file sul server web, non nel database.
Fonte	Il browser o il programma che effettua la richiesta.
Base giuridica	Art. 6(1)(f) GDPR. Interesse: funzionamento sicuro e ininterrotto. Bilanciamento: senza l'indirizzo completo, le richieste ripetute dallo stesso mittente non possono essere collegate e gli attacchi non possono essere respinti; un indirizzo troncato non consente questa distinzione. I log non vengono combinati con altri dati e vengono cancellati dopo un breve periodo.
Destinatari	Nessuno.
Paese terzo	Nessuno.
Conservazione	14 giorni: rotazione giornaliera con 14 generazioni, poi sovrascrittura (servizio di rotazione dei log del sistema, non il processo di cancellazione notturno dell'applicazione).
TOM	Sezione 8.

B.2 Registro delle visualizzazioni di pagina dell'applicazione

Campo	Voce
Finalità	Sicurezza e rilevamento degli abusi (chi richiede che cosa e con quale frequenza), tracciabilità degli accessi agli account, semplici statistiche di utilizzo senza un servizio di analisi.
Categorie di interessati	Tutti i visitatori del sito web e gli utenti dell'app in occasione di visualizzazioni di pagina effettive (nessuna richiesta in background, nessun invio di moduli).
Categorie di dati personali	Indirizzo IP completo, il paese da esso ricavato al momento della scrittura (database geografico locale, nessuna interrogazione a terzi), ID account per gli utenti connessi, indirizzo richiesto e pagina di provenienza (con i token di accesso in essi contenuti, come quelli dei link ai report o ai portali, mascherati), identificativo del browser e il tipo di dispositivo, il sistema operativo e il browser da esso ricavati, lingua, ora (access_logs). Durante “Visualizza come cliente” (B.14) non viene impostato alcun ID account, affinché le visualizzazioni di pagina dell'assistenza non compaiano nel registro del Cliente.
Fonte	La richiesta del browser.
Base giuridica	Art. 6(1)(f) GDPR. Interesse: prevenzione degli abusi e tracciabilità. Bilanciamento: come B.1; il periodo di conservazione è più lungo perché gli schemi di abuso diventano visibili nell'arco di settimane. Se l'indirizzo IP debba essere troncato o il periodo di conservazione ridotto è una questione aperta per la revisione legale.
Destinatari	Nessuno. I titolari di account ricevono le proprie visualizzazioni di pagina nell'esportazione dei dati.
Paese terzo	Nessuno.
Conservazione	60 giorni (ogni notte tra le 03:00 e le 03:05, srv/cron_status.php, impostazione “registro delle visualizzazioni di pagina”).
TOM	Sezione 8. L'indirizzo IP viene ricavato da un header inoltrato solo se la richiesta proviene dal nostro proxy a monte, e in tal caso solo dalla voce aggiunta da tale proxy; altrimenti chiunque potrebbe dichiarare a piacimento la propria provenienza.

B.3 Cookie e archiviazione nel browser

Campo	Voce
Finalità	Archiviazione tecnicamente necessaria: sessione, protezione contro la falsificazione di richieste tra siti (CSRF), conteggio dei limiti per le verifiche senza account, login, permanenza della connessione su richiesta, visualizzazione chiara o scura.
Categorie di interessati	Visitatori e utenti di formexposed.com.
Categorie di dati personali	Cookie di sessione bpid (identificativo di sessione; termina alla chiusura del browser; HttpOnly, SameSite=Lax, Secure tramite HTTPS). Cookie bp_remember solo dopo aver scelto “Resta connesso” (selettore e verificatore; 30 giorni). Local storage bp_theme (chiaro, scuro o sistema). Nell'area di amministrazione, inoltre, impostazioni di visualizzazione locali dei gestori. Per i limiti viene calcolato un hash dall'identificativo di sessione; l'identificativo stesso non viene memorizzato.
Non impostati	Nessun cookie di analisi, pubblicità o tracciamento. Il programma partner (B.33) funziona senza cookie. L'immagine del badge sulle pagine dei Clienti non imposta cookie (B.18). reCAPTCHA può impostare cookie di Google all'invio di un modulo protetto (B.23).
Base giuridica	Accesso al dispositivo terminale: strettamente necessario per il servizio richiesto dall'utente (§ 25(2) n. 2 TDDDG, la legge tedesca sulla protezione dei dati nelle telecomunicazioni e nei servizi digitali; art. 399(3) PKE, la legge polacca sulle comunicazioni elettroniche (Prawo komunikacji elektronicznej)). Trattamento: art. 6(1)(b) GDPR (account) e (f) (sicurezza, limiti).
Destinatari	Nessuno.
Paese terzo	Nessuno.
Conservazione	Sessione; 30 giorni per il token di permanenza. Il processo notturno cancella i token di permanenza scaduti nel database (remember_tokens); al logout, alla modifica della password e alla revoca di un dispositivo, immediatamente.
TOM	Sezione 8.

B.4 Verifica gratuita senza account – accettazione, limiti e monitoraggio degli abusi

Campo	Voce
Finalità	Chiunque può far verificare un dominio senza account. Affinché il campo di inserimento non diventi un'arma contro siti web di terzi, si applicano limiti graduati: una verifica anonima per dominio in sette giorni (dopodiché lo stesso report), limiti per indirizzo IP e per sessione in 24 ore, un limite giornaliero per l'intero sistema, un blocco per i domini molto recenti, blocklist e opt-out, solo indirizzi pubblici. Gli schemi sospetti vengono registrati e segnalati al gestore. I limiti per indirizzo IP, per sessione e per l'intero sistema, conteggiati ciascuno separatamente, si applicano anche alla verifica dal plugin senza account (un plugin con una coppia di chiavi vincolata conta per sito web anziché per indirizzo) e all'opt-out (B.30); lo strumento header gratuito (B.9) ha limiti propri per indirizzo IP e giorno e per l'intero sistema.
Categorie di interessati	Persone che avviano una verifica, una richiesta allo strumento header o un opt-out; server su cui è installato un plugin.
Categorie di dati personali	Registro di ogni richiesta: fonte (verifica, plugin, strumento header, opt-out), indirizzo IP completo, hash dell'identificativo di sessione, host verificato, paese ricavato dall'indirizzo IP, accettata o rifiutata con motivo, ora (check_throttle). Anomalie: tipo (indirizzo IP, sessione, paese, sistema), chiave (per il tipo “IP” l'indirizzo IP completo), schema, gravità, breve descrizione, orari di rilevamento e risoluzione, persona che risolve (abuse_flags). Lavoro: host, modalità, livello di attendibilità e un hash di sessione troncato come identificativo del richiedente (scan_jobs). Report: identificativo casuale, host, lingua, scadenza, prima visualizzazione, numero di visualizzazioni (reports). Età del dominio memorizzata in cache dall'interrogazione del registro (domain_age_cache).
Fonte	L'inserimento della persona; la sua richiesta; interrogazione del registro (RDAP) per l'età del dominio.
Base giuridica	Esecuzione della verifica richiesta: art. 6(1)(b) GDPR (utilizzo della verifica gratuita ai sensi delle Condizioni di servizio); in subordine, (f). Limiti e monitoraggio: art. 6(1)(f). Interesse: impedire che il servizio venga utilizzato come strumento contro siti web di terzi o come cannone per lo spam. Bilanciamento: senza il collegamento all'indirizzo e alla sessione, i limiti non potrebbero essere applicati; il periodo di sette giorni è breve quanto il limite più lungo conteggiato a partire da esso.
Destinatari	Google (reCAPTCHA all'invio, B.23). Per l'età del dominio, lo scanner interroga il servizio di reindirizzamento RDAP rdap.org, che inoltra al registro competente; viene trasmesso solo il nome di dominio. Quando si verifica un'anomalia, il gestore riceve un segnale tramite Telegram senza alcuna variabile (nessun host, nessun indirizzo). Il report può essere visto da chi dispone del suo link casuale.
Paese terzo	USA tramite reCAPTCHA (B.23).
Conservazione	Registro delle richieste 7 giorni (ogni notte, srv/cron_status.php). Anomalie risolte 90 giorni dopo la risoluzione; quelle non risolte restano finché qualcuno non le risolve (sezione 10). I report anonimi scadono dopo 30 giorni; il processo notturno cancella quindi report, lavoro, risultato della verifica, moduli, risultati e immagini (fe_reports_aufraeumen()). Un amministratore può sbloccare manualmente le voci relative a un indirizzo; ciò cancella il relativo registro delle ultime 24 ore.
TOM	Sezione 8. Arresto di emergenza per tutte le verifiche anonime nell'area di amministrazione; contropressione che non accetta nuove verifiche gratuite in presenza di arretrati.

B.5 Verifica di siti web di terzi tramite crawler

Campo	Voce
Finalità	Verifica di sicurezza dei moduli di contatto pubblici: protezioni contro spam e abusi, caratteristiche di protezione dei dati e di accessibilità, script di terzi incorporati, comportamento dopo il rifiuto nel banner dei cookie, visualizzazione su dispositivi mobili. Si applica alle verifiche senza account (B.4), ai domini in un account non ancora verificati e come base per lo studio (B.7) e la verifica dei potenziali clienti (B.8). Per i domini verificati in un account agiamo per conto del Cliente (A.4).
Comportamento del crawler	Identificativo proprio con un riferimento alla pagina del crawler; legge robots.txt prima della verifica e si ferma se una regola disallow copre la home page (lo stesso se robots.txt non è raggiungibile o si verifica un errore del server); le regole disallow per singoli sottopercorsi non vengono considerate separatamente. Polso dei moduli, recupero della prova, strumento header e ricerca di file esposti non leggono robots.txt. Al massimo otto pagine pubbliche per verifica, più fino a tre pagine con un clic su “Rifiuta” nel banner dei cookie, fino a tre pagine in visualizzazione smartphone, sonde attive per i domini verificati e fino a cinque pagine dietro un login (A.5); le pagine vengono caricate una dopo l'altra, non in parallelo; solo indirizzi pubblici, nessuna rete interna, i reindirizzamenti vengono ricontrollati; blocklist e opt-out vengono verificati prima dell'accettazione e una seconda volta nello scanner. Passivo: senza prova di controllo, per i Clienti non viene inviato nulla (eccezione: verifiche interne dei nostri domini di test e demo, B.6).
Categorie di interessati	Gestori dei siti web verificati (laddove siano persone fisiche, come le imprese individuali); persone casualmente visibili sulle pagine verificate.
Categorie di dati personali	Come A.4: indirizzi e titoli delle pagine, struttura dei moduli (nomi, tipi ed etichette dei campi, nessun valore dei campi), protezioni, script di terzi (indirizzi; gli ID account di pixel e strumenti di registrazione vengono sostituiti prima della memorizzazione), comportamento del banner dei cookie, screenshot (area visibile della home page, moduli). Se nel modulo compare un indirizzo del destinatario, solo il suo dominio (scans, forms, findings, scan_screenshots).
Fonte	Pagine accessibili pubblicamente.
Base giuridica	Art. 6(1)(f) GDPR. Interesse: esecuzione della verifica di sicurezza richiesta; segnalazione ai gestori dei siti web di punti deboli che possono danneggiare i loro visitatori. Bilanciamento: viene letto solo ciò che vede ogni visitatore, in misura ridotta e senza inviare nulla; il gestore può escludere in modo permanente il proprio dominio in qualsiasi momento senza prove. Le informazioni ai sensi dell'art. 14 GDPR sono fornite tramite la pagina del crawler, l'opt-out e l'Informativa sulla privacy; se ciò sia sufficiente ai sensi dell'art. 14(5)(b) è una questione aperta per la revisione legale.
Destinatari	Chi avvia il report e chiunque riceva da lui il link casuale; il modello linguistico locale sul nostro server laddove il tipo di modulo non sia chiaro (struttura del modulo, titolo e indirizzo della pagina, testo visibile del modulo). Gli avvisi di vulnerabilità relativi alle versioni dei plugin non compaiono mai nei report anonimi.
Paese terzo	Nessuno.
Conservazione	Anonimi: 30 giorni (B.4). Verifica dei potenziali clienti: 90 giorni (B.8). Studio: fino alla pubblicazione (B.7). Dominio in un account: al massimo 13 mesi, l'ultima verifica resta; immediatamente con il dominio. Verifiche interne del gestore senza dominio e senza report (come quelle create dalla riga di comando): nessun periodo di conservazione (sezione 10). I file temporanei sul server di scansione vengono cancellati dopo ogni esecuzione.
TOM	Sezione 8. In particolare: container di verifica separato con privilegi ridotti, file system in sola lettura, limite di memoria e rete propria; doppio controllo della destinazione.

B.6 Invii di prova attivi

Campo	Voce
Finalità	Verificare se un modulo di contatto accetta un invio senza protezione, se CAPTCHA, trappola (honeypot), token, convalida dell'indirizzo e-mail e limitazione della frequenza sono efficaci lato server e se è possibile iniettare header.
Presupposto	Per i Clienti, solo per i domini per i quali è stata fornita la prova di controllo (record DNS, meta tag, file o plugin collegato); inoltre il gestore utilizza uno strumento interno a riga di comando per creare verifiche con il livello “verificato” per i nostri domini di test e demo. Solo con l'interruttore globale attivato, solo per un modulo classificato con certezza come modulo di contatto generico. Mai per ordini, prenotazioni, registrazioni, newsletter, pagamenti, caricamenti di file, campi obbligatori con dati personali reali, o domini di autorità pubbliche, strutture sanitarie o istituti di istruzione.
Categorie di interessati	Il personale del Cliente che riceve le e-mail dei moduli.
Categorie di dati personali	L'invio di prova non contiene dati personali: mittente “FormExposed Security Scanner”, il nostro indirizzo del mittente o un indirizzo sotto .invalid, un oggetto contrassegnato e un testo nella lingua della pagina con un riferimento alla pagina del crawler e all'opt-out e il numero della verifica. Memorizzati da noi: la risposta della pagina, i risultati, un'immagine della pagina successiva (come A.4).
Portata	Al massimo cinque invii per verifica (impostazione, valore predefinito 5); ricorrenti con la frequenza di verifica del piano, giornalmente nel piano più alto.
Fonte	L'istruzione del Cliente.
Base giuridica	Esecuzione del contratto con il Cliente (art. 6(1)(b) GDPR); gli invii vanno al modulo del Cliente stesso. Per i destinatari presso il Cliente: l'organizzazione del Cliente.
Destinatari	Il Cliente (la sua e-mail del modulo).
Paese terzo	Nessuno tramite noi.
Conservazione	Risultati come A.4.
TOM	Sezione 8. L'header injection viene solo rilevata, mai eseguita con un destinatario reale; la convalida dell'indirizzo e-mail utilizza solo un dominio che non può esistere.

B.7 Studio “Indice di sicurezza dei moduli”

Campo	Voce
Finalità	Statistiche sulla protezione dei moduli di contatto in un paese o in un settore. Vengono pubblicati solo totali, senza nomi di siti web; segmenti solo a partire da 20 pagine con un modulo.
Categorie di interessati	Gestori dei siti web presenti nell'elenco; persone casualmente visibili.
Categorie di dati personali	Come B.5, solo passivo. Inoltre l'elenco: host, segmento, stato, lavoro (study_domains); studio con titolo, paese, totali dei risultati (studies).
Fonte	Un elenco di siti web pubblici compilato dal gestore; le pagine stesse.
Base giuridica	Art. 6(1)(f) GDPR. Interesse: affermazioni statistiche sullo stato della sicurezza dei moduli. Bilanciamento: passivo, rallentato (pochi lavori per esecuzione), si applicano blocklist e opt-out, pubblicazione solo come totali, i dati grezzi vengono cancellati.
Destinatari	Il pubblico, solo totali.
Paese terzo	Nessuno.
Conservazione	I dati grezzi (risultati delle verifiche, moduli, risultati, immagini, lavori) vengono cancellati alla pubblicazione (fe_studie_veroeffentlichen()). L'elenco degli host con il segmento resta in seguito; non esiste un periodo di conservazione per esso né per gli studi mai pubblicati (sezione 10). Il gestore decide quali elenchi vengono verificati e se gli studi vengono pubblicati.
TOM	Sezione 8.

B.8 Verifica dei potenziali clienti (modalità di acquisizione per le agenzie)

Campo	Voce
Finalità	Un'agenzia (piano Business) verifica passivamente il sito web di un potenziale cliente e riceve un report sintetico con il proprio marchio e il report passivo. Non contattiamo nessuno; è l'agenzia stessa a inoltrare il link.
Categorie di interessati	Gestore del sito web verificato; persone casualmente visibili; personale dell'agenzia che avvia la verifica.
Categorie di dati personali	Come B.5, solo passivo. Inoltre: area di lavoro, persona che avvia la verifica, host, identificativo casuale del report, ora (prospect_checks).
Fonte	L'inserimento dell'agenzia; pagine pubbliche.
Base giuridica	Art. 6(1)(f) GDPR (il nostro interesse a fornire il servizio e l'interesse dell'agenzia a un approccio fondato). I ruoli dell'agenzia e nostri e gli obblighi dell'agenzia nell'inoltrare il report sono questioni aperte per la revisione legale: se l'agenzia invia il report via e-mail senza richiesta o effettua una telefonata, si tratta di marketing diretto che richiede il consenso ai sensi dell'art. 398 PKE e del § 7(2) UWG (la legge tedesca contro la concorrenza sleale), anche tra imprese. Ciò è responsabilità dell'agenzia; le Condizioni di servizio la obbligano in tal senso.
Destinatari	L'agenzia e chiunque riceva da essa il link.
Paese terzo	Nessuno.
Conservazione	Report e risultato della verifica scadono dopo 90 giorni e vengono quindi cancellati dal processo notturno (fe_reports_aufraeumen()); la voce della verifica viene cancellata dopo 90 giorni nel processo giornaliero della protezione collettiva a partire dalle 04:00 (srv/cron_status.php). Con l'area di lavoro, immediatamente.
TOM	Sezione 8. Quota mensile (impostazione, valore predefinito 30); la stessa pagina entro sette giorni restituisce lo stesso report; si applica l'opt-out.

B.9 Strumento header senza account

Campo	Voce
Finalità	Valutazione gratuita (da A+ a F) degli header di sicurezza della home page di un dominio. Due richieste, nessun browser, nessun modulo, nessun invio.
Categorie di interessati	Persone che utilizzano lo strumento; gestori del dominio verificato.
Categorie di dati personali	Registro delle richieste come B.4 (fonte “headers”, indirizzo IP, hash di sessione, host). Risultato: host, valutazione, punti, header valutati (header_checks).
Base giuridica	Art. 6(1)(f) GDPR, come B.4 e B.5.
Destinatari	Google (reCAPTCHA, B.23).
Paese terzo	USA tramite reCAPTCHA.
Conservazione	Registro delle richieste 7 giorni; risultati dopo attualmente 90 giorni (processo di cancellazione notturno, parte “header_checks”, impostazione “headers_keep_days”). Per i domini in un account, la valutazione viene ricalcolata ogni giorno e memorizzata con il dominio.
TOM	Sezione 8. Limiti per indirizzo IP e giorno; si applica l'opt-out.

B.10 Account cliente

Campo	Voce
Finalità	Gestione degli account cliente, delle aree di lavoro e dei piani.
Categorie di interessati	Clienti (imprese) e membri dei loro team con un proprio account.
Categorie di dati personali	Indirizzo e-mail e forma normalizzata, password solo come hash, nome (obbligatorio), cognome e azienda (se indicati); l'applicazione non memorizza indirizzo e partita IVA, che vengono forniti solo presso Stripe (B.26); stato, lingua, modalità di visualizzazione, valuta, piano e stato di fatturazione, ID cliente e abbonamento Stripe, fine del periodo di fatturazione, disdetta alla fine del periodo, identificativi di conferma e reimpostazione con scadenza, nuovo indirizzo e-mail fino alla conferma, ora della registrazione, ultimo login e ultimo indirizzo IP, ora in cui tutte le sessioni sono state revocate, dati del secondo fattore (B.11), report mensile attivato/disattivato, ora dell'e-mail di promemoria, sblocchi tramite codici, codice di segnalazione e segnalazione (users). Aree di lavoro con nome, orari, stato (workspaces); appartenenza con ruolo e data di adesione (workspace_users).
Fonte	Registrazione e impostazioni da parte della persona; stato di fatturazione da Stripe.
Base giuridica	Art. 6(1)(b) GDPR (contratto). Ultimo indirizzo IP: (f) (sicurezza dell'account).
Destinatari	Stripe (B.26); fornitore del servizio di posta per le e-mail relative all'account (B.25). I membri della stessa area di lavoro vedono nome, indirizzo e-mail e ruolo degli altri membri.
Paese terzo	Tramite Stripe e il fornitore del servizio di posta.
Conservazione	Fino alla cancellazione da parte del titolare dell'account. Alla cancellazione, le aree di lavoro proprie del titolare che nessun altro utilizza vengono eliminate con tutti i domini e i relativi dati; le aree di lavoro con altri membri passano a un altro membro, prima agli amministratori e tra questi a quello che ne fa parte da più tempo. Vengono cancellati appartenenze, token di permanenza, dispositivi, chiavi API, codici Telegram aperti, feedback sui report (B.35) e la riga dell'account; un abbonamento a pagamento in corso viene prima terminato immediatamente presso Stripe, senza rimborso (www/ajax.php, fe_konto_reste_loeschen()). Una disdetta nell'area di fatturazione ha invece effetto alla fine del periodo; successivamente l'account prosegue con il piano gratuito. Ciò che resta è illustrato nella sezione 6.4. Gli account mai confermati e in cui non si è mai effettuato l'accesso vengono cancellati dopo 30 giorni, a meno che un altro membro sia collegato alla loro area di lavoro (processo di cancellazione notturno, parte “pending_accounts”). Non avviene alcuna cancellazione degli account inattivi. Se il contratto relativo all'account termina in altro modo, ad esempio per nostro recesso, cancelliamo l'account al più tardi 30 giorni dopo il termine del contratto; attualmente ciò avviene manualmente (impegno assunto nell'Accordo sul trattamento dei dati).
TOM	Sezione 8.

B.11 Login, dispositivi, secondo fattore e registro delle attività

Campo	Voce
Finalità	Protezione degli account: limitazione dei tentativi di login e di altri tentativi con password, visualizzazione e revoca dei dispositivi connessi, login con secondo fattore, tracciabilità delle modifiche.
Categorie di interessati	Titolari di account e membri dei team; persone che tentano un login, una registrazione o la password di un portale clienti.
Categorie di dati personali	Tentativi di login: indirizzo IP, indirizzo e-mail inserito, esito, ora (login_attempts). Dispositivi: hash dell'identificativo di sessione (mai l'identificativo stesso), collegamento al token di permanenza, indirizzo IP, identificativo del browser e il browser, il sistema operativo e il tipo di dispositivo da esso ricavati, orari di login, ultima attività e revoca, e per “Visualizza come cliente” l'identificativo della persona dell'assistenza (login_sessions). Token di permanenza per “Resta connesso”: selettore, verificatore, scadenza (remember_tokens). Secondo fattore: segreto cifrato, ora di attivazione, ultimo intervallo temporale utilizzato, codici di recupero solo come hash (in users). Registro delle attività: account, area di lavoro, azione, oggetto, dettagli, indirizzo IP, paese, ora (audit_logs). Contatori dei tentativi per login, secondo fattore, conferma della password, reimpostazione della password, registrazione e password dei portali clienti: una chiave HMAC ricavata dalla finalità e dall'ID account (per un indirizzo sconosciuto o per una reimpostazione, l'indirizzo e-mail in minuscolo), dall'indirizzo IP, da account e indirizzo IP insieme o dall'ID del portale (anche insieme all'indirizzo IP), numero di tentativi, scadenza; gli indirizzi e-mail e IP non vi sono memorizzati in chiaro (tabella auth_attempt_buckets).
Base giuridica	Art. 6(1)(b) GDPR in combinato disposto con l'art. 32 (elenco dei dispositivi, secondo fattore) e (f) (tentativi di login, registro delle attività). Interesse: protezione degli account dalla presa di controllo, documentazione delle modifiche (art. 5(2)). Bilanciamento: un indirizzo troncato non risponde alla domanda “ero io?”; il registro delle attività deve durare più a lungo di una controversia che sorge solo mesi dopo.
Destinatari	Nessuno. Il titolare dell'account vede i propri dispositivi e riceve tentativi di login, dispositivi e attività nell'esportazione dei dati; durante una sessione “Visualizza come cliente” non vi compaiono né l'indirizzo IP né il browser della persona dell'assistenza.
Paese terzo	Nessuno.
Conservazione	Tentativi di login 7 giorni; dopo un login riuscito, i tentativi falliti dallo stesso indirizzo vengono cancellati immediatamente. Contatori dei tentativi alla fine della loro finestra temporale (attualmente 15 minuti, un'ora per la reimpostazione della password e la registrazione); quelli scaduti vengono cancellati dall'accesso successivo e dal processo notturno. Dispositivi 90 giorni dopo l'ultimo utilizzo o dopo la revoca (processo di cancellazione notturno, parte “sessions”), immediatamente con l'account. I token di permanenza scadono dopo 30 giorni. Registro delle attività 365 giorni (ogni notte); quando un account viene cancellato, le sue voci restano fino alla fine del periodo di conservazione (sezione 6.4).
TOM	Sezione 8.

B.12 Prova della conclusione del contratto

Campo	Voce
Finalità	Dimostrare quale versione delle Condizioni di servizio, dell'Accordo sul trattamento dei dati e dell'Informativa sulla privacy un Cliente ha accettato o di cui ha preso atto al momento della registrazione, e che il Cliente utilizza il servizio per la propria attività professionale.
Categorie di interessati	Clienti.
Categorie di dati personali	Per documento: account, documento, versione (hash del testo visualizzato), occasione, indirizzo IP, identificativo del browser, ora (legal_consents). La versione visualizzata stessa con testo completo, lingua, titolo e indirizzo, una volta per versione (legal_versions; non contiene dati personali).
Base giuridica	Art. 6(1)(b) e (f) GDPR (prova della conclusione del contratto, difesa da pretese).
Destinatari	Nessuno. Il titolare dell'account riceve le proprie registrazioni nell'esportazione dei dati.
Paese terzo	Nessuno.
Conservazione	Finché esiste l'account; dopo la cancellazione dell'account, quattro anni dal consenso, poi cancellazione notturna (srv/cron_status.php). Motivazione nel codice: termine di prescrizione di tre anni dalla fine dell'anno, arrotondato per eccesso. Se il diritto polacco suggerisca un termine diverso è oggetto della revisione legale.
TOM	Sezione 8. Se manca uno dei tre documenti, la registrazione è chiusa.

B.13 Inviti al team

Campo	Voce
Finalità	Invitare altre persone in un'area di lavoro.
Categorie di interessati	Persone invitate.
Categorie di dati personali	Indirizzo e-mail, ruolo, identificativo dell'invito, persona che invita, scadenza, ora di accettazione (workspace_invites); l'e-mail di invito nella posta in uscita (B.25).
Fonte	Inseriti dal membro che invita.
Base giuridica	Art. 6(1)(b) GDPR in relazione al Cliente; nei confronti della persona invitata (f) (interesse del Cliente a coinvolgere il proprio team).
Destinatari	Fornitore del servizio di posta (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Paese terzo	Tramite il fornitore del servizio di posta.
Conservazione	Un invito è valido per 14 giorni e solo finché la persona che invita è proprietario o amministratore dell'area di lavoro. Inviti non accettati dopo la scadenza, quelli accettati 30 giorni dopo l'accettazione (ogni notte, srv/cron_status.php e parte “invites” in cfg/fristen_lib.php). Con l'area di lavoro, immediatamente.
TOM	Sezione 8.

B.14 “Visualizza come Cliente” da parte del supporto

Campo	Contenuto
Finalità	Un super admin vede l’applicazione così come la vede un Cliente, per risolvere una richiesta di supporto (“il pulsante a me non compare”).
Categorie di interessati	Il Cliente in questione; il super admin.
Categorie di dati personali	Tutto ciò che il Cliente vede nell’applicazione. Viene registrato: una riga dispositivo separata con l’identificativo del super admin (login_sessions), inizio e fine nel registro delle attività (audit_logs).
Base giuridica	Art. 6(1)(b) GDPR (supporto nell’ambito del servizio), in alternativa (f).
Limiti	Al massimo un’ora, poi disconnessione completa. La chiusura della visualizzazione disconnette completamente anche il super admin, compresa la sessione da cui proveniva; torna all’area di amministrazione solo accedendo di nuovo con password e secondo fattore. Termina immediatamente se il super admin viene declassato o bloccato. Tutto ciò che modifica l’account del Cliente è bloccato: password, indirizzo e-mail, secondo fattore, dispositivi, abbonamento, esportazione, cancellazione, trasferimento. Durante la sessione l’area di amministrazione è chiusa. Il Cliente vede l’accesso nel proprio elenco dei dispositivi e nell’esportazione dei dati come accesso del supporto.
Destinatari	Nessuno.
Paese terzo	Nessuno.
Conservazione	Riga dispositivo 90 giorni, registro delle attività 365 giorni.
Misure tecniche e organizzative	Sezione 8.

B.15 Domini, prova di controllo e monitoraggio

Campo	Contenuto
Finalità	Il servizio principale per i Clienti: gestire i domini nell’account, fornire la prova di controllo, effettuare controlli regolari e rilevare le modifiche. Ciò comprende il polso del modulo (una richiesta leggera senza browser ogni 10–30 minuti a seconda del piano), la sorveglianza quotidiana del DNS di posta e del certificato, la data di scadenza del dominio, le blocklist, i file esposti, le versioni visibili dall’esterno, l’inventario degli script, le modifiche visive al modulo, i disservizi dei fornitori di CAPTCHA e di posta e la sorveglianza delle vulnerabilità dei plugin per moduli.
Categorie di interessati	Clienti e membri dei loro team; gestori dei domini, qualora siano persone fisiche.
Categorie di dati personali	Dominio con host, identificativo pubblico, nota, etichetta del cliente, tipo e identificativo della prova, frequenza dei controlli, monitoraggio attivo/disattivo, finestre di manutenzione, valore di una richiesta di contatto, identificativi per badge, verifica di recapito e deploy hook, chiave del plugin, stati e risultati più recenti delle sorveglianze (DNS, certificato, autenticità dell’e-mail del modulo, blocklist, file esposti, header, versioni) (domains). Polso per pagina del modulo (form_pulse). Vulnerabilità ricavate dalle versioni dei plugin (vuln_hits). Inventario degli script con indirizzo, hash, dimensione, approvazione con persona che approva e motivazione (script_inventory, script_changes). Controlli come A.4. Per i file esposti vengono memorizzati percorso, gravità e tipo, mai il contenuto.
Richieste a terzi	Interrogazioni DNS (SPF, DMARC, MX, record di prova). Consultazione del registro tramite RDAP secondo la directory IANA: solo il nome di dominio. Blocklist DNS (SpamCop, PSBL, Mailspike, SURBL; Spamhaus solo con credenziali di accesso memorizzate, attualmente non utilizzato): indirizzi IP del server web e del server di posta e nome di dominio, nessun dato dei visitatori. Google Web Risk solo se configurato (attualmente non lo è): l’indirizzo della home page. Autorità di marcatura temporale: solo un valore hash (B.19). WPVulnerability: solo l’identificativo di un plugin o di un tema, oppure la versione di WordPress; il confronto con la versione installata del plugin lo effettuiamo noi stessi. Pagine di stato di Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun e Brevo: non viene trasmesso nulla oltre alla richiesta stessa.
Fonte	Cliente; richieste alla pagina del Cliente; directory pubbliche.
Base giuridica	Art. 6(1)(b) GDPR.
Destinatari	I servizi indicati non ricevono dati personali dei nostri Clienti, nella misura in cui i nomi di dominio e gli indirizzi dei server di un’impresa non sono dati personali; per le ditte individuali il nome di dominio può costituire un dato personale. I membri del workspace vedono il dominio.
Paese terzo	Le richieste possono raggiungere servizi situati in paesi terzi (ad esempio consultazioni del registro, blocklist). Viene trasmesso solo quanto indicato nella riga “Richieste a terzi”.
Conservazione	Fino alla cancellazione del dominio. fe_domain_loeschen() cancella quindi immediatamente risultati dei controlli, moduli, riscontri, immagini, report, job, destinazioni degli avvisi e registro degli avvisi, incidenti, codici Telegram, recapiti, polso, vulnerabilità e prove; tramite chiavi esterne, moduli monitorati, esecuzioni del browser, account di prova e contatori dei moduli; i dati del plugin dell’host, se nessun altro dominio vi fa riferimento. Vengono inoltre cancellati l’inventario degli script e le modifiche agli script del dominio; non hanno un proprio periodo di conservazione (sezione 6.4). Risultati dei controlli al massimo 13 mesi, l’ultimo resta.
Misure tecniche e organizzative	Sezione 8. Sorveglianza di file esposti e versioni solo per domini verificati, al massimo una richiesta per percorso, solo i primi 8 KB; sondare percorsi di terzi senza che sia richiesto sarebbe uno strumento di attacco.

B.16 Avvisi, incidenti ed escalation nei confronti del titolare dell’account

Campo	Contenuto
Finalità	Informare il Cliente su malfunzionamenti e modifiche, rispettare le finestre di manutenzione, prendere in carico e sottoporre a escalation gli incidenti. Se le destinazioni sono terzi, agiamo per conto del Cliente (A.3); se si tratta del titolare dell’account stesso, il trattamento è descritto qui.
Categorie di interessati	Titolari dell’account e membri del team in qualità di destinatari.
Categorie di dati personali	Come A.3. Le notifiche vengono visualizzate nella lingua del titolare dell’account.
Base giuridica	Art. 6(1)(b) GDPR.
Destinatari	Fornitore del servizio di posta; servizi di chat scelti (4.1).
Paese terzo	A seconda del canale (4.1).
Conservazione	Come A.3: registro dei recapiti 90 giorni, notifiche riepilogative 30 giorni dopo il recapito, incidenti fino alla risoluzione e successivamente 180 giorni. Destinazioni degli avvisi insieme al dominio.
Misure tecniche e organizzative	Sezione 8.

B.17 Report mensile agli account

Campo	Contenuto
Finalità	Il 1° di ogni mese a partire dalle 08:00 (recupero fino al 3), un’e-mail per account relativa a tutti i suoi domini: livello, punteggio e variazione, avvisi, bot bloccati, invio di e-mail, valore di confronto.
Categorie di interessati	Titolari di account attivi con il report mensile attivato.
Categorie di dati personali	Indirizzo e-mail, lingua, indicatori chiave dei domini.
Base giuridica	Art. 6(1)(b) GDPR (parte del servizio). È possibile disiscriversi nelle impostazioni; può essere disattivato centralmente.
Destinatari	Fornitore del servizio di posta (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Paese terzo	Tramite il fornitore del servizio di posta.
Conservazione	Nessuna conservazione separata; l’e-mail rimane nella coda di invio per 30 giorni (B.25).
Misure tecniche e organizzative	Sezione 8.

B.18 Badge e pagina pubblica di conferma

Campo	Contenuto
Finalità	Un Cliente può incorporare un’immagine badge nel proprio sito web e collegarla a una pagina pubblica di conferma. Il badge mostra “Protetto” solo se il dominio è verificato, il monitoraggio è in corso e l’ultimo controllo completato risale al massimo a 45 giorni prima e ha dato come esito “Protetto” o “Parzialmente protetto”; altrimenti mostra in modo neutro “Controllo del modulo di contatto”. La pagina di conferma indica il livello e la data, nessun singolo riscontro.
Categorie di interessati	Visitatori del sito web del Cliente il cui browser carica l’immagine; visitatori della pagina di conferma.
Categorie di dati personali	Al caricamento dell’immagine: indirizzo IP, ora, indirizzo richiesto, pagina di provenienza e identificativo del browser nel log del server web (B.1). L’indirizzo dell’immagine non avvia alcuna sessione, non imposta cookie e non scrive nel registro delle visualizzazioni di pagina. La pagina di conferma è una pagina normale (B.2, B.3).
Base giuridica	Art. 6(1)(f) GDPR. Interesse: fornire l’immagine e mantenere la sicurezza del funzionamento. Se il Cliente e noi siamo contitolari del trattamento per la trasmissione dell’indirizzo IP del visitatore, ai sensi della giurisprudenza sui contenuti di terzi incorporati, e se sia necessario un accordo ai sensi dell’Art. 26, è una questione aperta per la verifica legale. Il Cliente riceve un testo suggerito per la propria informativa sulla privacy.
Destinatari	Nessuno.
Paese terzo	Nessuno.
Conservazione	14 giorni (log del server web). L’immagine viene memorizzata nella cache per un’ora. Quando il badge viene disattivato, l’identificativo perde validità.
Misure tecniche e organizzative	Sezione 8.

B.19 Registro probatorio e marca temporale

Campo	Contenuto
Finalità	Un registro per dominio e mese (piani a pagamento): che cosa è stato controllato, con quale esito, che cosa è stato segnalato e che cosa è cambiato, come prova ai fini della responsabilizzazione, per assicuratori o per audit dei fornitori. Ogni versione riceve un numero di verifica; una pagina pubblica conferma dominio, periodo e indicatori chiave, senza dettagli. Dal 7 ottobre 2026 un’autorità di marcatura temporale conforme a RFC 3161 conferma l’ora.
Categorie di interessati	Clienti; indirettamente, persone che possono essere nominate nel registro come approvatori o come persone che hanno preso in carico un evento.
Categorie di dati personali	Dominio, mese, numero di verifica, hash del contenuto (SHA-512), riepilogo e dati del registro, risposta della marca temporale, autorità di marcatura temporale e ora, tentativi falliti (proof_docs).
Base giuridica	Art. 6(1)(b) GDPR.
Destinatari	L’autorità di marcatura temporale (predefinita Certum, di riserva DigiCert) riceve solo l’hash del registro, non il suo contenuto. Pubblico: indicatori chiave tramite la pagina di conferma. Il Cliente e chiunque riceva dal Cliente il registro o il numero di verifica.
Paese terzo	Nessun trasferimento di dati personali: un hash non consente di risalire al contenuto. L’autorità di riserva ha sede negli USA.
Conservazione	Fino alla cancellazione del dominio (fe_domain_loeschen()). La marca temporale non è una validazione temporale elettronica qualificata ai sensi di eIDAS.
Misure tecniche e organizzative	Sezione 8.

B.20 Plugin ed estensione: controllo, collegamento e trasmissione

Campo	Contenuto
Finalità	Il plugin WordPress e l’estensione TYPO3 possono richiedere un controllo (anche senza account), collegarsi a un account (l’installazione vale come prova di controllo con un clic nell’account), sbloccare funzioni di protezione, comunicare dati numerici ogni giorno (A.9) e segnalare immediatamente errori delle e-mail e la modalità di manutenzione.
Categorie di interessati	Clienti; gestori di siti web che utilizzano il plugin senza account.
Categorie di dati personali	Per host: versione del plugin e del CMS, numero di controlli, identificativo dell’ultimo report, hash del segreto di collegamento, primo e ultimo contatto (plugin_sites). Codici di collegamento monouso come hash con scadenza (plugin_connect_tokens). Codici di rollout di un’agenzia come hash con prefisso, etichetta, utilizzi, persona che li ha creati (workspace_connect_codes). Registro delle richieste con l’indirizzo IP del server chiamante (B.4). La chiave del plugin è visibile pubblicamente nell’head del sito web; è un hash del segreto, e il segreto stesso viene memorizzato solo come hash e mai restituito.
Base giuridica	Art. 6(1)(b) GDPR (account); senza account (f) (controllo richiesto, prevenzione degli abusi).
Destinatari	Nessuno.
Paese terzo	Nessuno.
Conservazione	I dati di un host vengono eliminati non appena nessun dominio vi fa più riferimento; la riga di un plugin senza account solo dopo 90 giorni senza contatto (ciclo notturno di cancellazione, parte “orphan_hosts”). Codici monouso un giorno dopo la scadenza. Codici di rollout insieme al workspace.
Misure tecniche e organizzative	Sezione 8. Dal 27 settembre 2026 il server accetta solo coppie di chiavi vincolate al sito web; i segreti di collegamento più vecchi e non vincolati sono stati cancellati.

B.21 Protezione collettiva (swarm)

Campo	Contenuto
Finalità	Difesa comune dallo spam: i siti web collegati segnalano i domini dei link contenuti in messaggi che il loro livello di protezione ha bloccato. Un dominio che compare su almeno tre siti web con almeno cinque occorrenze nell’arco di sette giorni viene inserito in un elenco che viene restituito a tutti i siti web collegati; il loro livello di protezione sposta i messaggi con tali link in quarantena, mai nel nulla.
Categorie di interessati	Titolari dei domini dei link segnalati, qualora siano persone fisiche (ad esempio il gestore di un sito di spam a proprio nome). Non i mittenti e i destinatari dei messaggi: indirizzi, testi e nomi non vengono segnalati.
Categorie di dati personali	Segnalazioni: tipo, dominio, host segnalante, giorno, occorrenze (swarm_signals). Elenco: tipo, dominio, numero di siti web e di occorrenze, orari (swarm_list). I grandi servizi, i domini dei nostri Clienti e le eccezioni impostate dal gestore non vengono mai inseriti nell’elenco.
Reti IP	La condivisione di reti IP (/24, /48) è stata predisposta. È disattivata e il plugin non ne segnala alcuna; verrà attivata solo dopo una verifica legale, perché gli indirizzi IP sono dati personali.
Base giuridica	Art. 6(1)(f) GDPR. Interesse: proteggere i moduli di tutti i Clienti dalle ondate di spam. Bilanciamento: solo domini, soglie minime contro l’avvelenamento dell’elenco, nessuna perdita di messaggi, rimozione possibile in qualsiasi momento.
Destinatari	Tutti i siti web collegati (l’elenco dei domini).
Paese terzo	A seconda dell’ubicazione dei siti web collegati; l’elenco può raggiungere anche siti web al di fuori del SEE. Costituisce un dato personale solo in casi limite (domini di persone fisiche). La base per il trasferimento ai sensi del Capo V GDPR per questi casi deve ancora essere determinata (questione aperta per la verifica legale).
Conservazione	Segnalazioni 30 giorni (ciclo swarm giornaliero dalle 04:00, cfg/swarm_lib.php). L’elenco viene ricalcolato ogni giorno; ciò che non raggiunge più la soglia viene escluso.
Misure tecniche e organizzative	Sezione 8.

B.22 Chiavi API, interfaccia di programmazione e server MCP

Campo	Contenuto
Finalità	Accesso degli strumenti propri del Cliente (REST API, Zapier, Make, server MCP per assistenti AI) ai domini, ai controlli e agli incidenti del Cliente.
Categorie di interessati	Clienti che creano chiavi.
Categorie di dati personali	Chiave solo come hash, prefisso, etichetta, momenti di creazione, ultimo utilizzo e revoca (api_keys). Chiamate al minuto (api_usage).
Base giuridica	Art. 6(1)(b) GDPR.
Destinatari	Lo strumento che il Cliente dota della chiave; è il Cliente a sceglierlo.
Paese terzo	A seconda dello strumento del Cliente.
Conservazione	Chiavi fino alla revoca, immediatamente insieme all’account; chiavi senza account (dati pregressi) di notte. Contatori delle chiamate dopo un giorno (occasionalmente ripuliti in occasione di una chiamata).
Misure tecniche e organizzative	Sezione 8.

B.23 reCAPTCHA e protezione propria dei moduli

Campo	Contenuto
Finalità	Difesa dagli accessi automatizzati ai nostri moduli: controllo gratuito, strumento per gli header, opt-out, accesso, registrazione, password dimenticata e reimpostazione della password, supporto e contatto. Inoltre, una protezione propria senza terzi: trappola (campo nascosto), controllo dei tempi firmato e token CSRF. Dal 29 ottobre 2026 si aggiunge la nostra protezione dei moduli formconfirmed (prova di lavoro e token di verifica monouso) per il controllo gratuito, la registrazione, l’accesso e “password dimenticata”.
Categorie di interessati	Persone che inviano questi moduli.
Categorie di dati personali	Presso Google: indirizzo IP, dati del browser e del dispositivo, dati comportamentali, cookie di Google. Presso di noi: la valutazione di Google (punteggio e azione) solo al momento del controllo, senza memorizzazione, nemmeno quando un invio viene respinto. Per la protezione propria dei moduli: indirizzo IP (memorizzato solo in forma abbreviata e sottoposto a hash), pagina, orari, campo trappola compilato sì/no; nessun contenuto.
Tempistica	Lo script di Google viene caricato solo all’invio di un modulo protetto, non all’apertura della pagina. La protezione propria dei moduli ottiene il suo compito all’apertura della pagina ed esegue il calcolo non appena il modulo viene utilizzato. Sul sistema di sviluppo reCAPTCHA è disattivato.
Base giuridica	Art. 6(1)(f) GDPR. Interesse: protezione dai bot, in particolare per il controllo gratuito, che altrimenti potrebbe essere utilizzato contro siti web di terzi. Se l’accesso all’apparecchiatura terminale richieda il consenso ai sensi del § 25 TDDDG o dell’Art. 399 PKE, anche se lo script viene caricato solo all’invio, è una questione aperta per la verifica legale. La protezione propria dei moduli non imposta cookie, non memorizza nulla nel browser e non crea alcuna impronta digitale; è destinata a sostituire reCAPTCHA in via definitiva.
Destinatari	Google Ireland Limited; Google LLC. Per la protezione propria dei moduli nessuno.
Paese terzo	USA (solo reCAPTCHA). Base: certificazione nell’ambito del EU-US Data Privacy Framework o clausole contrattuali tipo; da documentare in dettaglio.
Conservazione	reCAPTCHA: nessuna conservazione presso di noi; presso Google secondo le sue regole. Protezione propria dei moduli: identificativo sottoposto a hash 1 ora, token di verifica utilizzati al massimo 11 minuti, risultati delle verifiche senza indirizzo IP 30 giorni.
Indisponibilità	Se Google non risponde entro tre secondi o fornisce una risposta inutilizzabile, l’invio viene respinto; lo stesso vale per un token vuoto e per una risposta relativa a un’azione diversa da quella del modulo. Il controllo viene saltato solo quando reCAPTCHA è disattivato. Con la protezione propria dei moduli, un invio senza token di verifica valido viene respinto; se il servizio non era raggiungibile per il compito, l’invio viene consentito.
Misure tecniche e organizzative	Sezione 8.

B.24 Supporto e modulo di contatto

Campo	Contenuto
Finalità	Ricevere e rispondere alle richieste tramite la finestra di supporto e la pagina di contatto. Entrambe utilizzano lo stesso percorso e la stessa tabella.
Categorie di interessati	Richiedenti, che abbiano effettuato l’accesso o meno.
Categorie di dati personali	Account (se è stato effettuato l’accesso; vale allora l’indirizzo dell’account, non quello inserito), indirizzo e-mail, motivo da un elenco predefinito, testo fino a 4.000 caratteri, stato, indirizzo IP completo, paese, identificativo del browser, pagina di provenienza (solo percorsi propri), lingua, momenti di ricezione e di risposta (support_requests); voce nel registro delle attività (senza testo); conferma di ricezione al richiedente nella coda di invio (B.25), con il testo fino a 2.000 caratteri solo per i mittenti che hanno effettuato l’accesso, senza il testo per le richieste inviate senza accesso.
Base giuridica	Art. 6(1)(b) GDPR se la richiesta riguarda un contratto; altrimenti (f). Indirizzo IP completo: (f) (limite di tre richieste per ora e indirizzo, prevenzione degli abusi).
Destinatari	Fornitore del servizio di posta (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) per conferma e risposta. Telegram riceve un segnale fisso senza alcuna variabile (“c’è una nuova richiesta di supporto”) e quindi nessun dato personale.
Paese terzo	Tramite il fornitore del servizio di posta.
Conservazione	24 mesi (ciclo notturno di cancellazione, parte “support”); manualmente anche prima. In caso di cancellazione di un account, le richieste restano fino alla scadenza del periodo di conservazione (sezione 6.4).
Misure tecniche e organizzative	Sezione 8. reCAPTCHA, protezione propria dei moduli, limitazione della frequenza.

B.25 Invio di e-mail (coda di invio)

Campo	Contenuto
Finalità	E-mail transazionali: conferma della registrazione e di nuovi indirizzi e-mail, reimpostazione della password, inviti, avvisi, report mensili, conferme e report del portale, conferme di ricezione e risposte del supporto, promemoria sul periodo di prova e sulla configurazione, notifiche operative ai gestori. Nessuna pubblicità, nessuna e-mail a persone che non si sono registrate personalmente o che non sono state indicate come destinatari dal Cliente.
Categorie di interessati	Destinatari di queste e-mail.
Categorie di dati personali	Indirizzo del destinatario, oggetto, contenuto completo, indirizzo di risposta, finalità, canale di invio, stato, errore, tentativi, orari (mail_outbox). Il contenuto può includere link di conferma e di reimpostazione con identificativi validi.
Base giuridica	Art. 6(1)(b) GDPR; per le notifiche operative (f).
Destinatari	Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (invio); il titolare dell’account vede le e-mail inviate a lui nell’esportazione dei dati (senza contenuto).
Paese terzo	A seconda del luogo di trattamento del fornitore del servizio di posta; contratto e base per il trasferimento devono ancora essere documentati (sezione 4).
Conservazione	30 giorni (di notte, srv/cron_status.php). Questo periodo è volutamente il più breve tra i registri: un registro di invio lungo sarebbe una raccolta di chiavi valide. Il ciclo di stato verifica ogni cinque minuti se è previsto un nuovo tentativo.
Stato	L’invio di e-mail deve essere configurato prima del lancio. Finché il fornitore del servizio di posta, con la sua sede e la base giuridica, non è stato definito, i testi legali riportano un segnaposto.
Misure tecniche e organizzative	Sezione 8. Le e-mail non riuscite vengono ritentate a intervalli crescenti e abbandonate dopo un numero massimo di tentativi.

B.26 Pagamenti e fatturazione

Campo	Contenuto
Finalità	Stipula e gestione degli abbonamenti (mensili o annuali, con pagamento anticipato), periodo di prova di 14 giorni senza carta con promemoria tre giorni prima della scadenza, pagamento su fattura per gli abbonamenti annuali (disattivato per impostazione predefinita), sblocchi tramite codici di hoster e partner senza pagamento, fatturazione, conservazione a fini fiscali.
Categorie di interessati	Clienti.
Categorie di dati personali	Presso Stripe: indirizzo e-mail, nome, indirizzo di fatturazione, partita IVA, dati di pagamento, fatture; come metadati il nostro ID account e il piano. Presso di noi: ID cliente e ID abbonamento Stripe, piano, stato, fine del periodo, disdetta alla fine del periodo (users); eventi Stripe ricevuti solo con identificativo, tipo, stato e orari, senza contenuto (stripe_events); riscatti di codici di hoster con account, campagna e scadenza (bundle_redemptions). I dati delle carte non ci pervengono mai.
Fonte	Il Cliente nel checkout di Stripe; eventi da Stripe.
Base giuridica	Art. 6(1)(b) GDPR; per la conservazione a fini fiscali (c).
Destinatari	Stripe Payments Europe Limited (Irlanda); Stripe, Inc. (USA). Per parti dell’elaborazione dei pagamenti, Stripe agisce sotto la propria responsabilità; la ripartizione precisa dei ruoli fa parte della verifica legale.
Paese terzo	USA tramite Stripe, Inc.; base: Data Privacy Framework o clausole contrattuali tipo secondo le condizioni di Stripe.
Conservazione	Campi di fatturazione insieme all’account; un abbonamento in corso viene terminato prima della cancellazione dell’account. Fatture e documenti di fatturazione ai sensi della normativa fiscale polacca per cinque anni dalla fine dell’anno in cui è scaduto il termine di pagamento dell’imposta; sono conservati presso Stripe e possono essere consultati nel portale clienti di Stripe. Gli eventi Stripe e i riscatti di codici non hanno un periodo di conservazione (sezione 6.4).
Misure tecniche e organizzative	Sezione 8. Eventi Stripe accettati solo con firma valida; ogni evento viene elaborato una sola volta.

B.27 Backup

Campo	Contenuto
Finalità	Ripristino dopo un errore: cancellazione errata, migrazione danneggiata.
Categorie di interessati	Tutti coloro i cui dati si trovano nel database.
Categorie di dati personali	Dump completo e compresso del database dell’applicazione. Screenshot e file dei loghi sono conservati al di fuori del database e non fanno parte di questo backup. Le credenziali degli account di prova vi sono contenute solo in forma cifrata (A.5).
Procedura	Ogni notte alle 03:00, dopo il ciclo di cancellazione, affinché il backup non riporti ciò che i periodi di conservazione hanno appena cancellato. Il dump viene conservato solo dopo la verifica del suo contenuto (codice di uscita, numero di tabelle, riga finale). La domenica, un test di ripristino carica l’ultimo backup in un database temporaneo e lo confronta tabella per tabella. Se qualcosa non riesce, vengono inviati un segnale e un’e-mail ai gestori.
Base giuridica	Art. 6(1)(f) GDPR in combinato disposto con l’Art. 32(1)(c).
Destinatari	Nessuno.
Paese terzo	Nessuno.
Conservazione	14 giorni; i dump più vecchi vengono rimossi solo dopo un nuovo backup riuscito (cfg/backup_lib.php). Le cancellazioni effettuate in questo periodo raggiungono il backup solo alla sua scadenza; se i dati vengono ripristinati da un backup, le richieste di cancellazione vengono applicate nuovamente in seguito.
Ubicazione	I backup sono attualmente conservati nella stessa ubicazione del database e non sono cifrati separatamente; è prevista una copia cifrata in una seconda ubicazione (sezioni 8.1 e 10).
Misure tecniche e organizzative	Sezione 8.

B.28 Registro degli errori e allarme errori

Campo	Contenuto
Finalità	Individuare e correggere gli errori prima che un Cliente li segnali. I nuovi tipi di errore e le ondate di errori vengono segnalati ai gestori, oltre a un riepilogo giornaliero dalle 08:00.
Categorie di interessati	Utenti la cui richiesta provoca un errore; indirettamente, persone i cui dati compaiono in un messaggio di errore.
Categorie di dati personali	Livello, origine, messaggio, contesto in formato JSON, ID account della sessione, ora (error_logs). Tipi di errore: impronta, schema (da cui sono stati rimossi indirizzi e-mail, indirizzi, numeri e identificativi), un messaggio di esempio inalterato fino a 2.000 caratteri, prima e ultima occorrenza, conteggio (error_kinds).
Base giuridica	Art. 6(1)(f) GDPR (sicurezza operativa, Art. 32).
Destinatari	I gestori via e-mail tramite il fornitore del servizio di posta: per un nuovo tipo di errore, origine e testo grezzo del messaggio fino a 400 caratteri (non ripulito), oltre all’e-mail di riepilogo giornaliero; per un’ondata di errori viene inviato solo il segnale Telegram. Telegram riceve solo frasi fisse senza variabili (“Si è verificato un nuovo tipo di errore”, “Molti errori in poco tempo”).
Paese terzo	Tramite il fornitore del servizio di posta.
Conservazione	Registro degli errori 90 giorni (di notte). Tipi di errore senza periodo di conservazione (sezione 10). L’allarme errori è attivo nel sistema di produzione e disattivato nel sistema di sviluppo.
Misure tecniche e organizzative	Sezione 8.

B.29 Segnali operativi e monitoraggio dello stato

Campo	Contenuto
Finalità	Rilevare i disservizi: ogni cinque minuti un controllo dei componenti (home page, database, spazio su disco, heartbeat dello scanner, arretrato della coda), pagina di stato, segnale in caso di malfunzionamento e di cessato allarme, heartbeat verso un servizio di monitoraggio esterno affinché venga rilevato anche un disservizio completo; arretrato a monte dello scanner.
Categorie di interessati	Di norma nessuna.
Categorie di dati personali	Nessuna. Righe giornaliere per componente con il numero di controlli e l’ultimo errore (system_status_logs), heartbeat dello scanner (scanner_heartbeat), indicatori chiave giornalieri senza riferimento a persone (daily_stats). I segnali a Telegram sono frasi fisse senza variabili; l’heartbeat è una richiesta senza contenuto.
Base giuridica	Non applicabile, poiché non vi sono dati personali; in via precauzionale Art. 6(1)(f).
Destinatari	Telegram (frasi fisse); il servizio di monitoraggio esterno (solo la richiesta); i gestori via e-mail.
Paese terzo	Telegram al di fuori dell’UE; non vengono trasmessi dati personali.
Conservazione	Righe di stato 400 giorni (di notte).
Misure tecniche e organizzative	Sezione 8.

B.30 Opt-out – esclusione di un dominio

Campo	Contenuto
Finalità	Chiunque può escludere in modo permanente qualsiasi dominio dai controlli senza fornire prove; il blocco ha effetto immediato su tutti i canali di controllo (controllo gratuito, plugin senza account, studio, controllo di potenziali clienti, strumento per gli header) e anche per i domini di Clienti paganti con prova di controllo; il loro monitoraggio in corso termina con il successivo controllo programmato. Si applica al dominio e alla sua variante www, non ad altri sottodomini. Viene revocato solo da noi, su richiesta e con prova. Affinché gli abusi (ad esempio un concorrente che blocca domini altrui) possano essere individuati e annullati, il blocco viene registrato.
Categorie di interessati	Persone che escludono un dominio.
Categorie di dati personali	Dominio, motivazione facoltativa fino a 250 caratteri, origine, indirizzo IP, paese, identificativo del browser, ora; in caso di revoca, ora, persona che revoca il blocco e motivazione (blocklist). Registro delle richieste come B.4.
Base giuridica	Per l’esclusione, Art. 6(1)(f) GDPR. Interesse: dare attuazione, in modo permanente e su tutti i canali di controllo, alla volontà che un dominio non venga controllato. Se la persona che effettua l’esclusione è essa stessa un interessato, l’esclusione dà contemporaneamente attuazione alla sua opposizione ai sensi dell’Art. 21 (Art. 6(1)(c)). Per indirizzo, paese e identificativo del browser, (f) (individuazione degli abusi).
Destinatari	Google (reCAPTCHA, B.23).
Paese terzo	USA tramite reCAPTCHA.
Conservazione	Indirizzo IP, paese e identificativo del browser dopo 12 mesi (ciclo notturno di cancellazione, parte “optout_ip”). L’esclusione stessa resta in modo permanente, affinché abbia effetto.
Misure tecniche e organizzative	Sezione 8. Molti blocchi provenienti da un unico paese in poco tempo generano un’anomalia (B.4).

B.31 Promemoria dopo la registrazione

Campo	Contenuto
Finalità	Un’unica e-mail da due a 14 giorni dopo la registrazione agli account confermati senza un dominio confermato: “Aggiungi sito web” o “Conferma dominio”. Nessuna offerta, nessun prezzo, nessun upgrade; con l’indicazione che non verrà inviata di nuovo. Giorni feriali dalle 09:00 alle 18:00, al massimo 50 per ciclo.
Categorie di interessati	Nuovi titolari di account.
Categorie di dati personali	Indirizzo e-mail, lingua, ora dell’invio (campo “promemoria inviato” in users), dominio e stato della conferma.
Base giuridica	Art. 6(1)(b) GDPR (indicazione sulla configurazione del proprio account). Se l’e-mail sia da considerarsi una comunicazione relativa al rapporto contrattuale o un’informazione commerciale che richiederebbe il consenso (Art. 10 UŚUDE, la legge polacca sulla prestazione di servizi per via elettronica (ustawa o świadczeniu usług drogą elektroniczną); Art. 398 PKE; § 7 UWG) è una questione aperta per la verifica legale; il gestore può disattivarla centralmente.
Destinatari	Fornitore del servizio di posta (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Paese terzo	Tramite il fornitore del servizio di posta.
Conservazione	L’ora viene conservata per tutta la durata dell’account; l’e-mail 30 giorni nella coda di invio.
Misure tecniche e organizzative	Sezione 8. L’ora viene impostata prima dell’invio, così che un’interruzione non provochi una seconda e-mail.

B.32 Bot Telegram per gli avvisi ai Clienti

Campo	Contenuto
Finalità	Una chat Telegram viene collegata come destinazione degli avvisi: il Cliente riceve un link al nostro bot con un codice monouso; quando il destinatario preme “Avvia”, il nostro server legge il codice dai nuovi messaggi inviati al bot e memorizza l’ID della chat. A tal fine non è necessario alcun endpoint aperto da parte nostra (webhook).
Categorie di interessati	Clienti e le persone la cui chat Telegram viene collegata.
Categorie di dati personali	Codice monouso, dominio, account che lo ha creato, eventi, modalità di recapito, ID della chat, orari (telegram_links); l’ID della chat come destinazione (alerts). Telegram fornisce ulteriori dati del profilo insieme al messaggio; vengono valutati e memorizzati solo il codice e l’ID della chat.
Base giuridica	Art. 6(1)(b) GDPR; per i terzi in qualità di destinatari, A.3.
Destinatari	Telegram.
Paese terzo	Al di fuori dell’UE, nessuna decisione di adeguatezza; la scelta spetta al Cliente (4.1). Base e informativa sono questioni aperte per la verifica legale.
Conservazione	Un codice è valido per 30 minuti; le righe di collegamento vengono cancellate dopo un giorno quando viene creato un nuovo codice, i codici non utilizzati insieme all’account e al dominio. L’ID della chat come destinazione fino alla cancellazione della destinazione degli avvisi o del dominio.
Misure tecniche e organizzative	Sezione 8.

B.33 Programma partner e codici di sblocco

Campo	Contenuto
Finalità	Un account può segnalare nuovi Clienti tramite un codice di referral e riceve una commissione sulle loro fatture pagate per un numero limitato di mesi. Il codice viene trasmesso nell’indirizzo fino alla registrazione; non viene impostato alcun cookie. Hoster e partner possono emettere codici che sbloccano un piano per un periodo senza pagamento; una settimana prima della scadenza il Cliente riceve un promemoria.
Stato	Il programma partner è disattivato per impostazione predefinita finché non saranno in vigore le Condizioni per i partner.
Categorie di interessati	Partner e Clienti segnalati.
Categorie di dati personali	Codice di referral, partner segnalante e momento della segnalazione (in users); commissione con partner, Cliente, ID fattura Stripe, importo, valuta, commissione, stato, orari (partner_commissions). Sblocco con piano, scadenza, origine, promemoria (in users); campagne e riscatti (bundle_campaigns, bundle_redemptions).
Base giuridica	Art. 6(1)(b) GDPR (accordo di partnership); per il Cliente (f) (liquidazione della commissione, senza trasmettere al partner dati del Cliente oltre all’importo della commissione); documentazione fiscale (c).
Destinatari	Il partner vede le proprie commissioni.
Paese terzo	Nessuno.
Conservazione	Referral e sblocco insieme all’account. Commissioni e riscatti non hanno un periodo di conservazione nel codice; in quanto documenti contabili, le commissioni sono soggette a conservazione a fini fiscali (sezione 6.4).
Misure tecniche e organizzative	Sezione 8.

B.34 Punto di segnalazione delle vulnerabilità

Campo	Contenuto
Finalità	Ricevere segnalazioni di vulnerabilità in formexposed, secondo le regole indicate nella pagina Sicurezza e in /.well-known/security.txt.
Categorie di interessati	Persone segnalanti; persone i cui dati sono contenuti in una segnalazione come prova.
Categorie di dati personali	Indirizzo e-mail, nome, contenuto della segnalazione e allegati, così come li invia la persona segnalante. La segnalazione ci perviene via e-mail all’indirizzo ivi indicato; l’applicazione non la memorizza.
Base giuridica	Art. 6(1)(f) GDPR (sicurezza del servizio, Art. 32); se una segnalazione contiene dati personali di terzi come prova, ugualmente (f), allo scopo di eliminare la vulnerabilità.
Destinatari	Fornitore del servizio di posta e, fino alla configurazione della casella di posta, l’inoltro del dominio presso Namecheap (sezione 4).
Paese terzo	Tramite il fornitore del servizio di posta e, fino al passaggio, l’inoltro.
Conservazione	Non è stato fissato né viene applicato tecnicamente alcun periodo di conservazione (sezione 10). Il gestore deve ancora fissare il periodo; una soluzione ovvia sarebbe cancellare le prove relative a terzi una volta eliminata la vulnerabilità e trattare la corrispondenza come le richieste di supporto.
Misure tecniche e organizzative	Sezione 8.

B.35 Feedback su un report

Campo	Contenuto
Finalità	Ricevere feedback sotto un report (“C’è qualcosa di sbagliato in questo report?”) per individuare errori nel riconoscimento dei moduli. Il superadmin lo classifica (nuovo, confermato, corretto, respinto) e può scaricare i dati del controllo del report come caso di test (moduli con campi, motivazioni e riscontri, senza screenshot e senza testi inviati attivamente).
Categorie di interessati	Persone che visualizzano un report, con o senza accesso effettuato.
Categorie di dati personali	Categoria e controllo da elenchi predefiniti, indirizzo della pagina fino a 500 caratteri, testo fino a 1.000 caratteri, lingua, ora, identificativo del report, controllo, host; identificativo dell’account se è stato effettuato l’accesso; HMAC-SHA256 dell’indirizzo IP con una chiave segreta per il limite; stato, persona incaricata, momento della gestione (report_feedback). Registro delle attività: modifiche di stato e download di un caso di test. Nessun indirizzo e-mail, nessun indirizzo IP in chiaro.
Base giuridica	Art. 6(1)(f) GDPR (individuazione e correzione degli errori di riconoscimento; limite contro gli abusi).
Destinatari	Nessuno.
Paese terzo	Nessuno.
Conservazione	24 mesi (ciclo notturno di cancellazione, parte “report_feedback”); il checksum dell’indirizzo IP viene cancellato dopo 2 giorni (parte “report_feedback_ip”); immediatamente in caso di cancellazione dell’account. I casi di test scaricati non contengono dati sulla persona segnalante.
Misure tecniche e organizzative	Sezione 8. Protezione propria dei moduli (trappola, tempo firmato, CSRF), al massimo 5 segnalazioni all’ora e 20 al giorno per checksum, 10 per report; leggibile solo dai superadmin.

6. Conservazione – che cosa copre il ciclo notturno di cancellazione e che cosa no

La cancellazione automatica esiste e ha una sua collocazione. Un ciclo di stato (srv/cron_status.php) viene avviato ogni cinque minuti tramite la crontab del server web, sul sistema di produzione come sul sistema di sviluppo. Controlla i componenti, recupera la posta della verifica di recapito, pianifica i controlli e invia gli avvisi. Una volta al giorno, nella finestra dalle 03:00 alle 03:04, effettua le cancellazioni secondo i periodi di conservazione e poi crea il backup. Dal 27 settembre 2026 richiama inoltre il ciclo dei periodi di conservazione in cfg/fristen_lib.php (fe_fristen_lauf()), le cui parti vengono eseguite indipendentemente l’una dall’altra: se una non riesce, le altre proseguono e l’errore viene annotato nel registro degli errori.

Prova che il ciclo è in esecuzione: lo stato dei backup del sistema di sviluppo mostra un backup riuscito alle 03:00 dell’11 ottobre 2026; il backup viene creato nello stesso blocco subito dopo la cancellazione. Il ciclo scrive un log per ogni tabella cancellata solo sull’output standard, che la crontab scarta; non esiste una registrazione permanente di che cosa è stato cancellato e quando (sezione 10).

I periodi di conservazione che compaiono come segnaposto sono impostati nell’area di amministrazione, nelle impostazioni di conservazione. Il ciclo legge le stesse impostazioni; i testi indicano quindi sempre il periodo dopo il quale i dati vengono effettivamente cancellati.

6.1 Coperto dal ciclo giornaliero

Dati	Periodo di conservazione ed evento di attivazione	Posizione nel codice
Registro delle visualizzazioni di pagina (access_logs)	60 giorni	srv/cron_status.php
Registro delle attività (audit_logs)	365 giorni	srv/cron_status.php
Registro degli errori (error_logs)	90 giorni	srv/cron_status.php
Coda di invio (mail_outbox)	30 giorni	srv/cron_status.php
Token “Resta connesso” (remember_tokens)	dopo la scadenza (30 giorni)	srv/cron_status.php
Inviti non accettati (workspace_invites)	dopo la scadenza (14 giorni)	srv/cron_status.php
Tentativi di accesso (login_attempts); contatori dei tentativi (auth_attempt_buckets)	7 giorni; i contatori alla scadenza della loro finestra temporale (attualmente 15 minuti, un’ora per reimpostazione della password e registrazione), anche al successivo accesso	srv/cron_status.php
Registro delle richieste dei controlli senza account (check_throttle)	7 giorni	srv/cron_status.php
Codici monouso per il collegamento del plugin (plugin_connect_tokens)	1 giorno dopo la scadenza	srv/cron_status.php
Anomalie risolte (abuse_flags)	90 giorni dopo la risoluzione	srv/cron_status.php
Report scaduti insieme a risultato del controllo, moduli, riscontri, immagini e job (solo senza un dominio in un account)	anonimi 30 giorni, potenziali clienti 90 giorni	fe_reports_aufraeumen()
Registro dei recapiti degli avvisi (alert_log)	90 giorni	fe_alert_log_aufraeumen()
Righe di stato (system_status_logs)	400 giorni	srv/cron_status.php
Registrazioni dei consensi di account cancellati (legal_consents)	una volta cancellato l’account e quando il consenso ha 4 anni	srv/cron_status.php
Dati orfani di domini cancellati: risultati dei controlli, job, dati degli avvisi, incidenti, codici Telegram, recapiti, polso, vulnerabilità, prove, inventario degli script e modifiche agli script	immediatamente al ciclo successivo	fe_fristen_lauf(), parti “orphan_scans”, “orphan_rows”
Dati del plugin di host senza dominio; riga del plugin senza account	immediatamente; riga dopo 90 giorni senza contatto	parte “orphan_hosts”
Risultati dello strumento per gli header (header_checks)	attualmente 90 giorni	parte “header_checks”
Risultati dei controlli di un dominio con moduli, riscontri, immagini, report, job	13 mesi; resta l’ultimo completato per ogni dominio	parte “old_scans”
Esecuzioni del browser, job del browser completati, serie temporali (form_browser_runs, scan_jobs, form_performance)	13 mesi	parti “browser_runs”, “browser_jobs”, “form_performance”
Contatori dei moduli (form_metrics), dati giornalieri del plugin e notifiche di modifica (plugin_stats, plugin_changes)	13 mesi	parti “form_metrics”, “plugin_stats”
Dispositivi connessi (login_sessions)	90 giorni dopo l’ultimo utilizzo o la revoca	parte “sessions”
Inviti accettati	30 giorni dopo l’accettazione	parte “invites”
Richieste di supporto (support_requests)	24 mesi	parte “support”
Feedback sui report (report_feedback)	24 mesi; checksum dell’indirizzo IP 2 giorni	parti “report_feedback” e “report_feedback_ip”
Versioni PDF dei report nella cache (var/pdf)	7 giorni	parte “pdf_cache”
Indirizzo IP, paese e identificativo del browser nell’opt-out (blocklist)	12 mesi; l’esclusione resta	parte “optout_ip”
Iscritti ai portali clienti (client_subscribers)	non confermati 30 giorni; disiscritti 3 anni	parte “subscribers”
Account mai confermati, insieme al workspace	30 giorni senza accesso, a meno che non vi sia associato un altro membro	parte “pending_accounts”
Chiavi API senza account (dati pregressi)	immediatamente	parte “api_keys”

6.2 Al di fuori della finestra delle 03:00

Dati	Periodo di conservazione ed evento di attivazione	Posizione nel codice
Copie nella casella di controllo della verifica di recapito	dopo l’elaborazione, ogni cinque minuti	fe_zustellung_abholen()
Associazioni della verifica di recapito (delivery_log)	180 giorni, a ogni recupero	fe_zustellung_abholen()
Testo cifrato dell’account di prova nei job (scan_jobs)	dopo l’esecuzione, al più tardi dopo un’ora	server di scansione; fe_login_aufraeumen()
Incidenti (alert_incidents) con i relativi tentativi di recapito dell’escalation	finché non risolti; 180 giorni dopo la risoluzione	fe_vorfaelle_aufraeumen() in cfg/vorfall_lib.php
Notifiche riepilogative inviate (alert_queue)	30 giorni dopo il recapito	cfg/kanal_lib.php
Segnalazioni swarm (swarm_signals)	30 giorni, ogni giorno dalle 04:00	cfg/swarm_lib.php
Controlli di potenziali clienti (prospect_checks)	90 giorni, ogni giorno dalle 04:00	srv/cron_status.php
Codici di collegamento Telegram (telegram_links)	1 giorno, alla creazione di un nuovo codice	cfg/kanal_lib.php
Contatori delle chiamate API (api_usage)	1 giorno, occasionalmente in occasione di una chiamata	cfg/agentur_lib.php
Disservizi risolti dei fornitori (provider_incidents), cache delle vulnerabilità (vuln_cache)	rispettivamente 90 e 30 giorni; nessun dato personale	cfg/anbieter_lib.php, cfg/luecken_lib.php
Dati grezzi degli studi	alla pubblicazione	fe_studie_veroeffentlichen()
Backup	14 giorni, dopo un nuovo backup riuscito	cfg/backup_lib.php
Log del server web	14 giorni	rotazione dei log di sistema

6.3 In caso di cancellazione da parte del Cliente

• Cancellazione di un dominio (fe_domain_loeschen()): risultati dei controlli con moduli, riscontri e file immagine, report, job, destinazioni degli avvisi, registro dei recapiti, coda dei riepiloghi, incidenti, codici Telegram, recapiti, polso, vulnerabilità, registri probatori, il dominio dai portali clienti con una selezione fissa; tramite chiavi esterne, moduli monitorati con esecuzioni del browser, osservazioni e serie temporali, account di prova, contatori dei moduli; i dati del plugin dell’host, se nessun altro dominio vi fa riferimento. Vengono inoltre cancellati anche l’inventario degli script e le modifiche agli script del dominio; non hanno un proprio periodo di conservazione (sezioni 6.4 e 10). I dati rimasti senza un dominio associato dal periodo precedente al 27 settembre 2026 vengono eliminati dal ciclo notturno (parti “orphan_scans”, “orphan_rows”).
• Cancellazione di un workspace (fe_arbeitsbereich_daten_loeschen()): in aggiunta, brand compreso il logo, portali clienti compresi gli iscritti, codici di rollout, controlli di potenziali clienti; inoltre inviti e appartenenze.
• Cancellazione di un account: termina immediatamente presso Stripe un abbonamento a pagamento in corso, senza rimborso; trasferisce o cancella i workspace di proprietà del titolare; cancella appartenenze, token “Resta connesso”, dispositivi, chiavi API con i contatori, codici Telegram non utilizzati e la riga dell’account.
• Cancellazione di un account di prova (fe_login_loeschen()): sovrascrive il testo cifrato, cancella la riga, elimina i job in attesa.

6.4 Che cosa il ciclo non copre

Questo elenco è il più importante. Indica i dati per i quali non esiste un periodo di conservazione automatico o che sopravvivono a una cancellazione.

Dati	Che cosa si applica	Valutazione
Dati dell’account compreso l’ultimo indirizzo IP (users)	fino alla cancellazione da parte del titolare dell’account; nessuna cancellazione degli account inattivi	dati contrattuali; manca una regola per gli account inattivi da lungo tempo senza abbonamento
Registro delle attività, visualizzazioni di pagina, registro degli errori di un account cancellato	restano con ID account e indirizzo IP fino alla scadenza del rispettivo periodo di conservazione	voluto (prova delle azioni anche dopo la cessazione); l’ID non rimanda più ad alcun account
Richieste di supporto di un account cancellato	restano fino a 24 mesi con il vecchio ID account	voluto; l’ID non viene eliminato
Registrazioni dei consensi di un account cancellato	finché il consenso non ha 4 anni (calcolati dal consenso, non dalla cancellazione dell’account)	voluto (sezione B.12)
Anomalie non risolte con indirizzo IP (abuse_flags)	finché qualcuno non le risolve	punto aperto (sezione 10)
Tipi di errore con messaggio di esempio inalterato (error_kinds)	nessun periodo di conservazione	punto aperto (sezione 10)
Inventario degli script e modifiche agli script (script_inventory, script_changes)	nessun periodo di conservazione proprio; conservati finché esiste il dominio e cancellati insieme a esso	punto aperto (sezione 10)
Iscritti a portali clienti revocati	fino alla cancellazione del workspace	punto aperto (sezione 10)
Chiavi API e codici di rollout revocati	fino alla cancellazione dell’account o del workspace	solo hash, prefisso ed etichetta; di scarsa rilevanza
Elenco degli host degli studi (study_domains), studi mai pubblicati	nessun periodo di conservazione	punto aperto (sezione 10)
Controlli interni senza dominio e senza report (risultati dei controlli, moduli, riscontri, screenshot)	nessun periodo di conservazione; nessun percorso di cancellazione li copre	punto aperto (sezione 10)
Commissioni, riscatti di codici, eventi Stripe	nessun periodo di conservazione	rilevanza contabile; periodo da fissare ai sensi della normativa fiscale
Età del dominio in cache (domain_age_cache)	nessun periodo di conservazione	solo nome di dominio e data di registrazione
Risultato dell’autenticazione dell’e-mail del modulo con dominio del mittente	insieme al dominio; sovrascritto a ogni ricezione	vedi A.1
Esclusioni nell’opt-out	permanenti	voluto; senza permanenza nessuna esclusione ha effetto
E-mail nella casella del punto di segnalazione e nella casella generale	nessun periodo di conservazione tecnico	punto aperto (sezione 10)

6.5 Al di fuori del database

• Gli screenshot sono conservati come file al di fuori della directory web e vengono cancellati insieme al relativo risultato del controllo (tutti i percorsi di cancellazione sopra indicati cancellano anche i file).
• I file dei loghi del brand vengono cancellati quando vengono sostituiti e insieme al workspace.
• Sul server di scansione viene creata per ogni job una directory temporanea con risultato e immagini; viene cancellata dopo ogni esecuzione, anche in caso di errore.
• I backup sono conservati sul server web (B.27).
• I log del server web con l’indirizzo IP completo vengono conservati per 14 giorni (B.1).

7. Processi decisionali automatizzati, profilazione e valutazione

formexposed valuta siti web, non persone. A nostro giudizio, il servizio non adotta alcuna decisione che produca effetti giuridici che riguardano una persona o che incida in modo analogo significativamente sulla sua persona (Art. 22(1) GDPR). Esistono tuttavia valutazioni automatizzate e blocchi automatici. Li elenchiamo affinché la classificazione possa essere verificata.

Meccanismo	Che cosa fa	Chi riguarda
Punteggio e giudizio di un controllo	Somma ponderata dei livelli di protezione mancanti (CAPTCHA, trappola, token, controllo dei tempi, CAPTCHA inefficace, configurazione esposta nota), da 0 a 100; da cui “Esposto”, “Parzialmente protetto” o “Protetto”. Il giudizio sul sito web segue il peggiore dei moduli di contatto riconosciuti come tali dalle regole (non dal modello linguistico); senza modulo di contatto non c’è alcun giudizio. I pesi possono essere impostati nell’area di amministrazione.	Gestori di siti web; per le ditte individuali, indirettamente una persona. Il giudizio non ha conseguenze giuridiche; è un riscontro corredato di prove e istruzioni.
Classificazione del tipo di modulo	Prima le regole, un modello linguistico locale solo se le regole restituiscono “sconosciuto”. Decide se è consentito un invio di prova attivo (solo per un modulo di contatto riconosciuto con certezza dalle regole). I moduli classificati dal modello linguistico non vengono mai inviati e non contano ai fini del punteggio e del giudizio.	Il Cliente e i destinatari delle e-mail dei suoi moduli; effetto protettivo: in caso di dubbio non viene inviato nulla.
Badge	Mostra “Protetto” solo a condizioni fisse (B.18), altrimenti un testo neutro.	Cliente; nessun effetto sui visitatori.
Limiti e blocchi per controllo gratuito, strumento per gli header e opt-out	Respingono le richieste se vengono raggiunti i limiti per indirizzo, sessione, dominio o sistema, se il dominio è troppo recente o di età sconosciuta oppure se si trova nella blocklist.	Richiedenti; effetto: un servizio gratuito viene negato per ore o giorni. Un amministratore può sbloccare un indirizzo; le richieste tramite la pagina di contatto arrivano a una persona.
Anomalie	Schemi (molti domini da un unico indirizzo, raffiche di richieste, molti rifiuti, molti opt-out da un unico paese, limite giornaliero raggiunto) vengono registrati e segnalati. Non bloccano di per sé; i blocchi derivano dai limiti.	Richiedenti.
Blocco dell’accesso	Dopo attualmente otto accessi non riusciti da un indirizzo nell’arco di 15 minuti, gli accessi da tale indirizzo vengono temporaneamente respinti. Inoltre, tutti i tentativi di accesso, compresi quelli riusciti, vengono conteggiati per account e indirizzo IP (attualmente otto), per account su tutti gli indirizzi (molti di più, contro i tentativi distribuiti) e per indirizzo IP (attualmente 80) nell’arco di 15 minuti, così come i codici del secondo fattore (dieci per account nell’arco di 15 minuti); oltre tali soglie i tentativi vengono respinti. I tentativi non riusciti da un altro indirizzo non escludono quindi più il proprietario dal suo account. Allo stesso modo sono limitate le conferme della password (cinque per account nell’arco di 15 minuti), le e-mail di reimpostazione (tre per indirizzo all’ora, con risposta invariata), le registrazioni (dieci per indirizzo IP all’ora) e i tentativi di inserimento della password di un portale clienti (dieci per portale e indirizzo IP, 50 per portale nell’arco di 15 minuti).	Persone che accedono, si registrano o aprono un portale clienti; effetto limitato nel tempo, la reimpostazione della password resta possibile.
Soglia reCAPTCHA	Respinge gli invii al di sotto di un punteggio Google; soglia per punto di utilizzo (attualmente 0,7 per controllo e opt-out). Vengono respinte anche le risposte relative a un’azione diversa e gli invii per i quali Google non risponde entro tre secondi.	Persone che inviano i nostri moduli; effetto: un nuovo tentativo o la via della pagina di contatto.
Protezione collettiva (swarm)	Inserisce automaticamente un dominio di link in un elenco al raggiungimento di soglie minime; i livelli di protezione dei siti web collegati spostano i messaggi con tali link in quarantena.	Mittenti di messaggi alle pagine dei Clienti. Effetto: il messaggio viene trattenuto, non cancellato, e può essere sbloccato dal gestore del sito web. La decisione sul messaggio viene presa dal plugin del gestore sul sito web del gestore, non da noi.
Valori di confronto	“Protetto meglio del X % dei siti controllati”, solo da totali di almeno 20 host.	Gestori di siti web; nessun effetto.

Ciò che più si avvicina all’Art. 22 è il livello di protezione del plugin sulle pagine dei Clienti, che trattiene automaticamente gli invii. Si tratta di un trattamento effettuato dal gestore del sito web sul server del gestore (A.10). Non cancella nulla, ma sposta i messaggi in quarantena, e il gestore può sbloccare qualsiasi messaggio. Né lì né presso di noi ha luogo alcuna profilazione dei visitatori; non esiste un identificativo dei visitatori che colleghi un messaggio a un altro.

8. Misure tecniche e organizzative (Art. 32) – descrizione generale

Questa sezione è la descrizione generale ai sensi dell’Art. 30(1)(g) e (2)(d) GDPR. La versione dettagliata si trova nella pagina Misure tecniche e organizzative. Ciascuna delle misure seguenti è comprovata nel codice o nella configurazione. Le misure non ancora attuate si trovano nella stessa sezione (8.1), affinché la descrizione sia completa.

Ambito	Misura in vigore
Cifratura del trasporto	HTTPS per sito web, app e interfacce; HSTS; cookie di sessione e del token “Resta connesso” solo tramite HTTPS, HttpOnly, SameSite=Lax.
Controllo degli accessi (autenticazione)	Password solo come hash, quelle nuove con almeno dieci caratteri e al massimo 72 byte; blocco dell’accesso dopo ripetuti tentativi non riusciti e limiti di tentativi per account e indirizzo IP insieme, per account e per indirizzo IP, affinché i tentativi non riusciti da un altro indirizzo non escludano il proprietario; limiti di tentativi anche per conferme della password, reimpostazione della password (con la stessa risposta e lo stesso tempo di risposta), registrazioni e password dei portali; accesso a due fattori (TOTP) con segreto cifrato, protezione contro il riutilizzo dei codici e codici di recupero sottoposti a hash; nuovo identificativo di sessione a ogni accesso, gli identificativi non emessi dal server non vengono accettati; “Resta connesso” non disponibile per i super admin, ogni token valido una sola volta; la modifica dell’indirizzo e-mail invalida un link di reimpostazione non ancora utilizzato; i dispositivi possono essere revocati singolarmente o tutti insieme; l’elenco dei dispositivi contiene solo l’hash dell’identificativo di sessione.
Controllo degli accessi (autorizzazione)	Ruoli per workspace (proprietario, admin, lettore); le autorizzazioni vengono verificate rispetto all’oggetto, mai rispetto a un identificativo proveniente dal modulo; account di prova, “Fix it for me” e controlli attivi solo per proprietari e admin; “Visualizza come Cliente” limitato nel tempo e bloccato per le azioni che modificano l’account, la sua chiusura disconnette completamente, ritorno all’area di amministrazione solo con password e secondo fattore; inviti validi solo finché la persona che invita è proprietario o admin; indirizzi di webhook e canali di chat mostrati ai lettori solo abbreviati all’host; il nome host di un dominio verificato non può essere modificato.
Sicurezza delle applicazioni	Token CSRF; istruzioni di database preparate; protezione propria dei moduli (trappola, controllo dei tempi firmato); reCAPTCHA sui moduli pubblici; limitazione della frequenza per supporto, controlli e interfacce; una sola chiamata “Fix it for me” per workspace alla volta, affinché la quota valga anche per richieste simultanee; Content Security Policy con protezione dal framing che consente l’esecuzione solo degli script che recano l’autorizzazione (nonce) della rispettiva risposta; indirizzo IP dagli header inoltrati solo dal nostro proxy e solo dalla voce che esso ha aggiunto; token di accesso mascherati nel registro delle visualizzazioni di pagina.
Segreti	Chiavi API, codici di rollout, segreti di collegamento del plugin, codici monouso e password dei portali solo come hash; credenziali degli account di prova cifrate in modo asimmetrico, chiave privata solo sul server di scansione; webhook firmati; eventi Stripe solo con firma valida.
Minimizzazione dei dati	La verifica di recapito non memorizza alcun contenuto né indirizzi completi dei mittenti; gli indirizzi dei destinatari nei moduli solo come dominio; gli ID account negli indirizzi degli script vengono sostituiti; dati numerici del plugin solo da elenchi predefiniti; testi di errore dell’invio di e-mail solo come categoria; segnali Telegram senza variabili; immagini del controllo tramite browser con campi di input mascherati; nessuno screenshot dietro un login.
Isolamento dello scanner	Ogni controllo nel proprio container: tutte le capability Linux rimosse, nessuna escalation dei privilegi, file system di sola lettura, limiti di memoria e di processi, rete propria; verifica della destinazione rispetto a reti private e locali prima dell’accettazione e nello scanner, anche dopo i reindirizzamenti; service worker bloccati, connessioni WebSocket chiuse. Richieste del server web (prova di controllo, strumento per gli header, ricerca di file, polso, RDAP, certificati, webhook e avvisi via chat) solo sulle consuete porte web e solo esattamente all’indirizzo verificato, webhook e avvisi via chat solo tramite HTTPS.
Archiviazione	Screenshot al di fuori della directory web, recuperabili solo tramite il report; report a indirizzi casuali con noindex; directory dei backup leggibile solo dal servizio.
Disponibilità e ripristino	Backup notturno con verifica del contenuto, test di ripristino settimanale, allarme in caso di errore; controllo dei componenti ogni cinque minuti con segnale ed e-mail; heartbeat esterno; arresto di emergenza per i controlli anonimi; contropressione in caso di arretrato.
Tracciabilità	Registro delle attività per accessi, modifiche, cancellazioni, accessi del supporto e approvazioni; registro degli errori con allarme.
Cancellazione	Periodi di conservazione in un unico punto del codice, dalle stesse impostazioni dei testi (sezione 6); catene di cancellazione per dominio, workspace e account, con le eccezioni della sezione 6.4.
Diritti degli interessati	Esportazione con un clic di tutti i dati dell’account in un file, basata su un elenco consentito di campi, senza segreti.
Organizzazione	Area di amministrazione solo per account con diritti di super admin, bloccata durante “Visualizza come Cliente”; sistemi di sviluppo e di produzione separati, il sistema di sviluppo dietro un’ulteriore barriera di accesso; trasferimento dei testi legali dopo l’approvazione tramite uno strumento che rifiuta bozze e segnaposto.

8.1 Misure non ancora attuate

• Nessuna cifratura del database a riposo (rilevato l’11 ottobre 2026). Fanno eccezione le credenziali degli account di prova e il segreto del secondo fattore, cifrati a livello di campo.
• Connessioni interne non cifrate in modo uniforme. Le connessioni all’interno della nostra rete interna non sono cifrate in modo uniforme. Le credenziali degli account di prova vi transitano solo in forma cifrata.
• Nessun backup in una seconda ubicazione. I backup sono attualmente conservati nella stessa ubicazione del database e non sono cifrati separatamente; è prevista una copia cifrata in una seconda ubicazione. Fino ad allora proteggono da un comando di cancellazione errato, non dalla perdita dell’ubicazione.
• Rafforzamento dell’amministrazione dei server non completato. La sicurezza dell’accesso amministrativo ai nostri server non raggiunge ancora lo standard che intendiamo garantire per l’esercizio; il rafforzamento prosegue. Non pubblichiamo dettagli, perché aiuterebbero un attaccante; li forniamo a un’autorità di controllo su richiesta.
• Nessun registro funzionale delle letture nell’area di amministrazione. Le azioni di scrittura vengono registrate nel registro delle attività; chi ha semplicemente visualizzato quale richiesta di supporto o quale report può essere determinato solo dal registro delle visualizzazioni di pagina (60 giorni).
• Nessun registro permanente delle cancellazioni. Ciò che il ciclo notturno ha cancellato non viene registrato (sezione 6).
• Nessun secondo punto di controllo indipendente. La sonda in una seconda ubicazione non è configurata (A.6).

9. Responsabile della protezione dei dati – valutazione ai sensi dell’Art. 37 GDPR

Esito: a nostro giudizio non sussiste l’obbligo di designarlo. La valutazione fa parte della verifica legale e verrà ripetuta non appena cambi una delle circostanze elencate di seguito.

L’Art. 37(1) prescrive la designazione in tre casi.

• Lettera (a) (autorità pubblica o organismo pubblico) non si applica.
• Lettera (b) (attività principali che richiedono il monitoraggio regolare e sistematico degli interessati su larga scala): la nostra attività principale è il controllo regolare e sistematico di siti web e moduli, non l’osservazione di persone. Non creiamo profili di visitatori, non utilizziamo tracciamento e non colleghiamo alcun messaggio a un altro. La verifica di recapito (A.1) fa transitare messaggi reali dei visitatori attraverso la nostra casella di posta, ma ai fini dell’associazione valuta solo gli header e i primi 8 KB e non memorizza alcun contenuto; osserva i percorsi di recapito, non le persone. Gli account dei Clienti e i registri sono accessori all’attività aziendale.
• Lettera (c) (trattamento su larga scala di categorie particolari ai sensi dell’Art. 9 o di dati relativi a reati ai sensi dell’Art. 10 come attività principale): non soddisfatta. Categorie particolari possono comparire incidentalmente nelle copie delle e-mail dei moduli (A.1), nelle pagine dietro un login (A.5) o nel codice incollato (A.7); la rilevazione incidentale non è un’attività principale.

L’Art. 37(4) consente al diritto nazionale di prevedere ulteriori casi. Stiamo facendo verificare da un avvocato se il diritto polacco ci imponga di designarlo.

Eventi che richiedono una nuova valutazione: attivazione della protezione collettiva con reti IP; una funzione che riconosce i visitatori attraverso più messaggi o siti web; memorizzazione di contenuti della verifica di recapito; un Cliente i cui moduli riguardano prevalentemente categorie particolari (salute, candidature) con la verifica di recapito attivata su larga scala; il primo dipendente con accesso ai dati dei clienti. Una designazione volontaria resta possibile; in tal caso si applicano integralmente gli Art. da 37 a 39.

A parte: se per singole attività di trattamento sia necessaria una valutazione d’impatto sulla protezione dei dati ai sensi dell’Art. 35 lo chiarisce la pagina Valutazione d’impatto sulla protezione dei dati. La sua valutazione preliminare conclude che una DPIA è necessaria per la protezione collettiva (B.21) e per gli studi nella misura prevista (B.7) e viene effettuata da noi, e che per la verifica di recapito (A.1) è necessaria nella configurazione tipica, come obbligo del Cliente, che supportiamo in tal senso.

10. Punti aperti e misure previste

I punti seguenti sono comprovati nel codice, nello schema o nella configurazione, non presunti. Descrivono la situazione alla data di questa versione; la classificazione è nostra e non anticipa alcuna valutazione giuridica. Sono ordinati in base al loro peso per gli interessati, non in base alla facilità con cui possono essere risolti. Le misure previste e la loro priorità sono indicate nella Valutazione d’impatto sulla protezione dei dati.

Punto aperto	Che cosa è comprovato	Rilevanza
Fornitore del servizio di posta senza contratto documentato	Per Namecheap, Inc. (Private Email), Phoenix, Arizona, USA non sono documentati il contratto, i luoghi di trattamento e la base per il trasferimento. Le e-mail dell’account, gli avvisi e la casella di controllo con messaggi reali dei visitatori passano attraverso questo fornitore.	Le disposizioni pertinenti sono l’Art. 28(2) e (4) e il Capo V GDPR. La stipula e la documentazione sono previste prima del lancio.
Basi per i servizi di chat e reCAPTCHA aperte	Avvisi a Telegram (nessuna decisione di adeguatezza), Slack, Discord, Microsoft Teams e Google Chat; reCAPTCHA senza richiesta di consenso.	Questioni aperte per la verifica legale; fino ad allora, informativa e base non sono definitive.
La casella di controllo può trattenere messaggi in caso di malfunzionamenti	La cancellazione avviene dopo un’elaborazione riuscita; se il recupero non riesce, le copie restano fino al successivo ciclo riuscito. Non viene emesso alcun avviso se nella casella si accumula un arretrato per un periodo prolungato.	Le copie contengono richieste reali dei visitatori.
Nessun backup in una seconda ubicazione, nessuna cifratura del database a riposo	Sezione 8.1. È prevista una copia cifrata del backup in una seconda ubicazione.	Un singolo evento nell’ubicazione colpirebbe contemporaneamente dati e backup; un supporto di memorizzazione rubato sarebbe leggibile.
Anomalie non risolte senza periodo di conservazione	Le anomalie con l’indirizzo IP completo come chiave vengono cancellate solo 90 giorni dopo la risoluzione; ciò che non viene mai risolto resta.	Riguarda il principio di limitazione della conservazione (Art. 5(1)(e)); la cancellazione dipende dalla risoluzione manuale. È previsto un periodo di conservazione fisso (misure della valutazione d’impatto sulla protezione dei dati).
Tipi di errore con messaggio di esempio senza periodo di conservazione	Il messaggio di esempio viene memorizzato inalterato fino a 2.000 caratteri; lo schema ripulito rimuove indirizzi e numeri, l’esempio no.	I messaggi di errore possono contenere indirizzi e-mail, nomi host o indirizzi IP.
Inventario degli script senza un proprio periodo di conservazione	L’inventario degli script e le modifiche agli script vengono cancellati insieme al dominio (FE_DOMAIN_TABELLEN), anche in caso di cancellazione del workspace o dell’account e nel ciclo notturno per i dati orfani; non hanno un proprio periodo di conservazione. Contengono indirizzi degli script, indirizzi delle pagine e, per le approvazioni, la persona che approva e una motivazione in testo libero.	Riguarda il principio di limitazione della conservazione (Art. 5(1)(e)); il registro delle modifiche con le approvazioni continua a crescere finché esiste il dominio.
Iscritti a portali revocati	Un portale revocato viene bloccato, non cancellato; i suoi iscritti restano fino alla cancellazione del workspace.	La finalità (invio del report) è venuta meno con la revoca.
Elenchi degli studi senza periodo di conservazione	Dopo la pubblicazione restano host e segmenti; anche gli studi mai pubblicati conservano i loro dati grezzi.	L’impegno “i dati grezzi vengono cancellati” vale solo per gli studi pubblicati.
Controlli interni senza percorso di cancellazione	I controlli con livello di attendibilità “interno” che non hanno né un dominio né un report (studi e controlli creati dal gestore dalla riga di comando) non sono coperti da alcun percorso di cancellazione; con essi restano moduli, riscontri e screenshot di siti web di terzi.	Riguarda il principio di limitazione della conservazione (Art. 5(1)(e)); colpisce persone che non sanno nulla del controllo. Valutato come rischio elevato nella Valutazione d’impatto sulla protezione dei dati.
La prova di controllo non viene rinnovata	La prova di controllo viene verificata una sola volta; nel codice non esiste alcun percorso attraverso il quale un dominio la perda di nuovo.	Gli invii di prova attivi, la ricerca di file e la scansione dietro il login proseguono anche dopo un cambio di proprietario o di incarico.
Scansione dietro il login: trasporto verso la pagina del Cliente	Come indirizzo di login è consentito http oltre a https, e gli errori di certificato sulla pagina del Cliente non interrompono il login.	Le credenziali degli account di prova potrebbero essere intercettate nel percorso verso la pagina del Cliente.
La cancellazione dipende da una finestra temporale	Il blocco giornaliero viene eseguito solo se un ciclo di stato si avvia tra le 03:00 e le 03:04. Se questo singolo ciclo non riesce (database irraggiungibile, server riavviato), la cancellazione e il backup di quel giorno non avvengono; non c’è alcun recupero. Ciò che è stato cancellato non viene registrato in modo permanente.	I periodi di conservazione vengono così prolungati silenziosamente di un giorno. Una finestra mancata non attiva alcun allarme; viene segnalato solo un backup che viene eseguito e non riesce. L’elenco di configurazione nell’area di amministrazione mostra la data dell’ultimo backup riuscito.
Alcune cancellazioni dipendono dal monitoraggio	Lo svuotamento della casella di controllo della verifica di recapito, la cancellazione di incidenti, notifiche riepilogative inviate, segnalazioni swarm e controlli di potenziali clienti, nonché l’eliminazione delle copie residue degli account di prova nei job avvengono nella parte di pianificazione del ciclo di stato, che funziona solo mentre il monitoraggio è attivato nell’area di amministrazione; le associazioni della verifica di recapito vengono cancellate solo mentre è configurata una casella di controllo.	Se il monitoraggio viene disattivato centralmente o la casella viene rimossa, questi periodi di conservazione si interrompono senza che nessuno se ne accorga.
Punto di segnalazione e caselle di posta senza periodo di conservazione	Le segnalazioni di vulnerabilità e le altre e-mail in arrivo sono conservate al di fuori dell’applicazione; non è stato fissato alcun periodo di conservazione.	Le segnalazioni possono contenere prove relative a terzi.
I valori dei campi nascosti vengono letti durante il controllo	Lo scanner legge il valore dei campi nascosti dei moduli fino a 24 caratteri e gli attributi data fino a 60 caratteri per riconoscere timestamp e token. Nella mappa dei campi e nei riscontri finiscono solo nome del campo, tipo, etichetta e risultato del riconoscimento, non il valore.	Nessuna lacuna di memorizzazione; il valore si trova solo nella memoria di lavoro del container di scansione durante il controllo. Un valore precompilato (ad esempio un numero cliente) viene letto nel processo, ma non memorizzato.
Dominio del mittente derivato nel risultato dell’autenticazione	A.1.	Per i domini personali dei visitatori, dati personali provenienti da un messaggio reale.
Rafforzamento dell’amministrazione dei server non completato; connessioni interne non cifrate in modo uniforme	Sezione 8.1. Il rafforzamento prosegue; non forniamo dettagli pubblicamente.	Un incidente di sicurezza a livello di server colpirebbe contemporaneamente applicazione, database e backup.
Rilevazione sul sistema di sviluppo	Schema, codice e impostazioni sono stati rilevati sul sistema di sviluppo.	Codice e schema corrispondono al sistema di produzione; le impostazioni possono differire e devono essere nuovamente verificate lì prima del lancio.

11. Aggiornamento del presente registro

L’Art. 30 richiede che il registro sia tenuto in forma scritta e messo a disposizione dell’autorità di controllo su richiesta. Ciò richiede una persona responsabile e un intervallo con cui il registro viene verificato rispetto al sistema anziché rispetto alla sua versione precedente.

• Responsabilità: Lukas Wójcik, titolare. Viene riesaminato ogni anno e ogni volta che un’attività di trattamento cambia.
• Eventi che richiedono un aggiornamento: un sub-responsabile del trattamento nuovo o modificato, in particolare la scelta del fornitore del servizio di posta; una nuova tabella o un nuovo campo con dati personali; una modifica dei periodi di conservazione o delle catene di cancellazione in cfg/fristen_lib.php o srv/cron_status.php; un nuovo canale di avviso o una nuova richiesta a un terzo; l’attivazione di una funzione disattivata per impostazione predefinita (protezione collettiva con reti IP, sonda, domini propri, programma partner, pagamento su fattura, Spamhaus o Google Web Risk); il trasferimento su altri server.
• Procedura: ogni affermazione contenuta qui deriva da codice, schema o rilevazione. Un riesame che si limita a leggere il testo non ha verificato nulla: schema e catene di cancellazione vengono rilevati di nuovo, i segnaposto restano segnaposto, i punti aperti vengono chiusi o riportati con motivazione.
• Rapporto con altri documenti: il presente registro non sostituisce l’Informativa sulla privacy, l’Accordo sul trattamento dei dati, le Misure tecniche e organizzative né l’elenco dei Sub-responsabili del trattamento. Se tali documenti e il presente registro divergono, la divergenza costituisce un riscontro.
• Le modifiche al presente documento sono elencate nella pagina Modifiche ai documenti contrattuali.