Misure tecniche e organizzative

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

Versione 1.1 · Ultimo aggiornamento: 22 ottobre 2026

Misure ai sensi dell'art. 32 GDPR con cui LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polonia, protegge il servizio formexposed. La presente pagina costituisce parte integrante dell'Accordo sul trattamento dei dati come Allegato 2.

1. Ambito di applicazione e principio

Le misure si applicano a tutti i dati trattati dal servizio: ai dati che trattiamo per conto dei nostri Clienti (descritti nell'Accordo sul trattamento dei dati) e ai dati per i quali siamo noi stessi titolari del trattamento, come gli account cliente e i log. Non esistono livelli di protezione separati per le due categorie; ciò che protegge l'account protegge anche i dati trattati in qualità di responsabile.

Struttura ai sensi dell'art. 32(1) GDPR. La pseudonimizzazione e la cifratura (lettera a)) sono trattate nella sezione 4; la riservatezza, l'integrità, la disponibilità e la resilienza permanenti dei sistemi (lettera b)) nelle sezioni 3, 5, 6 e 7; la capacità di ripristinare tempestivamente la disponibilità in caso di incidente (lettera c)) nella sezione 7.1; la procedura per testare, verificare e valutare regolarmente l'efficacia (lettera d)) nella sezione 9. Abbiamo selezionato le misure sulla base dei rischi descritti nella nostra Valutazione d'impatto sulla protezione dei dati, tenendo conto dello stato dell'arte e dei costi di attuazione.

Principio: misurato anziché previsto. Qui è indicato solo ciò che è stato effettivamente attuato nel codice o nell'esercizio. Ciò che è pianificato ma non ancora attuato è espressamente elencato come “pianificato” nella sezione 10. Una misura che qui manca non è tacitamente in vigore.

I nomi delle macchine, gli indirizzi interni, le porte, i nomi utente e le versioni del software non sono volutamente indicati. Non aiutano nessuno a valutare le misure, ma aiutano chi vuole aggirarle. Chi ne ha bisogno per un audit ai sensi dell'Accordo sul trattamento dei dati li riceve nel corso di tale audit in via riservata, nella misura necessaria per l'audit.

2. Struttura del servizio

Il servizio funziona su due server di proprietà del fornitore in Polonia, situati nella stessa rete interna:

Server web con database. Fornisce l'applicazione, ospita il database, invia le notifiche ed esegue il backup dei dati. È l'unico configurato per accettare richieste da Internet.
Server di scansione. Esegue in un browser le verifiche dei siti web di terzi e propri ed esegue il modello linguistico che classifica singoli moduli e aggiunge codice in “Fix it for me”. Non è configurato per accettare richieste da Internet, ma preleva autonomamente i propri lavori dal server web e vi restituisce i risultati.

Nell'esercizio non è coinvolto alcun fornitore di hosting, data center o cloud, e nulla viene inviato a un servizio di IA esterno. Quali terzi ricevono dati è indicato nella pagina Sub-responsabili del trattamento.

3. Riservatezza

3.1 Controllo dell'accesso fisico

I server si trovano in locali del fornitore in Polonia non aperti al pubblico. Solo il titolare vi ha accesso (secondo quanto dichiarato dal gestore). L'indirizzo esatto della sede non è volutamente indicato qui.

3.2 Controllo degli accessi: accesso al servizio

Le password sono memorizzate solo come hash con il metodo standard di PHP (bcrypt). Se il metodo standard cambia, l'hash viene rinnovato al login successivo. Per un tentativo di login con un indirizzo sconosciuto, il server calcola comunque un hash, affinché il tempo di risposta non riveli se un account esiste. Analogamente, la risposta a una richiesta di reimpostazione della password non rivela né con il testo né con la durata se l'account esiste; le e-mail di reimpostazione vengono inviate allo stesso indirizzo al massimo tre volte all'ora. Le nuove password devono essere lunghe almeno dieci caratteri e non possono superare 72 byte (UTF-8), perché bcrypt non considera i byte successivi. La modifica della password disconnette tutti gli altri dispositivi; la reimpostazione tramite il link disconnette tutti i dispositivi e il link è valido una sola volta.
Blocco dopo tentativi falliti. I login falliti sono conteggiati per indirizzo IP; dopo troppi tentativi in poco tempo (attualmente otto in 15 minuti), il login da quell'indirizzo viene temporaneamente bloccato. Un login riuscito azzera questo contatore. I tentativi vengono cancellati dopo sette giorni. Inoltre, prima di ogni verifica della password viene conteggiato un tentativo per account (per un indirizzo sconosciuto, per indirizzo inserito) e per indirizzo IP, compresi quelli riusciti: attualmente al massimo otto per account dallo stesso indirizzo IP e 80 per indirizzo IP in 15 minuti; per account si applica un limite notevolmente più alto su tutti gli indirizzi complessivamente, contro i tentativi distribuiti. I tentativi falliti da un altro indirizzo non escludono quindi più il titolare da un account. Questi contatori contengono solo una chiave HMAC, nessun indirizzo e-mail o IP in chiaro, e scadono con la loro finestra temporale. Se l'archivio dei contatori non è disponibile, il login viene rifiutato, non lasciato passare. Lo stesso tipo di limite si applica alla conferma della password prima di una modifica della password o dell'indirizzo, all'attivazione o disattivazione del secondo fattore, al trasferimento di un'area di lavoro, all'esportazione dei dati e alla cancellazione dell'account (cinque tentativi per account in 15 minuti), alle registrazioni (dieci per indirizzo IP all'ora) e alle password dei portali clienti (dieci tentativi per portale e indirizzo IP, 50 per portale in 15 minuti).
Secondo fattore. Ogni account può attivare il login con un codice monouso ai sensi della RFC 6238 (TOTP). Il relativo segreto è memorizzato cifrato nel database; la chiave non è memorizzata nel database, quindi un estratto del database da solo non basta. Un codice accettato non è valido una seconda volta. Dieci codici di recupero sono memorizzati solo come hash. I codici monouso e di recupero sono limitati a dieci tentativi per account in 15 minuti, anche durante la configurazione.
Area di amministrazione solo con secondo fattore. L'area di amministrazione del gestore si apre solo agli account con il secondo fattore attivato. La checklist di configurazione segnala ogni account amministratore senza secondo fattore.
Sessioni. Il cookie di sessione non può essere letto dagli script (HttpOnly), viene inviato solo tramite HTTPS (Secure) e non viene inviato con richieste da siti di terzi che potrebbero modificare qualcosa (SameSite=Lax). Al login viene creato un nuovo ID di sessione, affinché un ID impiantato in precedenza non sia più valido; il server non accetta un ID di sessione che non ha emesso esso stesso. Ogni account vede i propri dispositivi connessi e può disconnetterli singolarmente.
“Resta connesso” è facoltativo ed è valido per 30 giorni, ma non per gli account con diritti di amministrazione; questi accedono sempre con password e secondo fattore. Il token è composto da due parti; la parte di verifica è memorizzata nel database solo come hash. Ogni utilizzo lo sostituisce con uno nuovo e, anche in caso di richieste simultanee, ogni token è valido una sola volta, affinché un token rubato venga notato al più tardi alla successiva visita autentica.
Link nelle e-mail. I link per confermare l'indirizzo e reimpostare la password sono memorizzati nel database solo come hash. Il link di reimpostazione è valido per un'ora, il link per confermare una registrazione per 72 ore, il link per confermare un indirizzo modificato per 24 ore. Se l'indirizzo e-mail viene modificato, un link di reimpostazione aperto diventa non valido.
Interfacce. Le chiavi API, i codici di collegamento delle estensioni e i codici di distribuzione sono memorizzati solo come hash. Le chiavi API possono essere utilizzate solo un numero limitato di volte al minuto; i codici di collegamento delle estensioni sono validi per 15 minuti e una sola volta.
Protezione dai bot sui moduli pubblici (registrazione, login, password, verifica, strumento header, opt-out, assistenza e contatto): Google reCAPTCHA, che viene caricato solo al momento dell'invio. Viene accettata solo una risposta valida di Google con un punteggio sufficiente per esattamente l'azione del modulo; se Google non risponde entro tre secondi, l'invio viene rifiutato. I dettagli si trovano nell'Informativa sulla privacy.

3.3 Controllo degli accessi: amministrazione dei server

Il server raggiungibile da Internet utilizza un filtro di pacchetti per consentire solo i servizi che offre e blocca automaticamente gli indirizzi dopo ripetuti login falliti all'amministrazione del server.
I processi automatizzati tra i server utilizzano chiavi proprie con diritti strettamente limitati. La chiave con cui il server web distribuisce nuove versioni dello scanner può eseguire sul server di scansione solo un elenco fisso di comandi e può solo copiare, in sola scrittura, nella directory dello scanner; con essa non è possibile un login interattivo e ogni comando rifiutato viene registrato. Analogamente, il server di scansione può scrivere screenshot solo in una directory specifica sul server web.
Il processo che serve il sito web non ha né accesso in scrittura all'installazione di produzione né una chiave per il server di scansione. Una distribuzione avviata nell'area di amministrazione si limita a registrare un lavoro, che viene eseguito da un processo separato.
I segreti come le credenziali del database e le chiavi sono conservati in file di configurazione al di fuori della directory servita e non vengono copiati durante la distribuzione. La configurazione del server web non viene distribuita tramite l'interfaccia web.

3.4 Controllo delle autorizzazioni: diritti all'interno del servizio

Ruoli. Ogni area di lavoro ha i ruoli proprietario, amministratore e lettore. Modificare, cancellare, invitare e memorizzare credenziali è riservato a proprietari e amministratori; solo il proprietario può modificare i ruoli e rimuovere membri. Un invito è valido solo finché la persona che lo ha inviato è ancora proprietario o amministratore. I lettori vedono gli indirizzi dei webhook e dei canali di chat solo abbreviati all'host, perché il solo indirizzo consente di pubblicare nel canale. Il controllo avviene sul server, non solo nell'interfaccia.
Vincolo all'area di lavoro. I domini e le impostazioni sono accessibili solo ai membri dell'area di lavoro. Per ogni verifica il Servizio crea un report con un link casuale che non può essere indovinato; i risultati e gli screenshot di una verifica sono accessibili tramite questo link senza login, gli screenshot solo insieme al link del relativo report. Il link compare nell'account e negli avvisi; chi lo inoltra inoltra il report.
Le richieste che modificano lo stato richiedono un token di sicurezza per sessione (protezione CSRF), che viene confrontato in tempo costante.
“Visualizza come cliente”. Per l'assistenza, il gestore può vedere l'applicazione come la vede un Cliente. La visualizzazione termina dopo un'ora, blocca le modifiche a password, indirizzo, secondo fattore, dispositivi, abbonamento, esportazione e cancellazione, chiude nel frattempo l'area di amministrazione ed è registrata. Al suo termine il gestore viene disconnesso completamente; può tornare all'area di amministrazione solo accedendo di nuovo con password e secondo fattore. Il Cliente può vederla nella propria esportazione dei dati.
Amministrazione. Solo pochi account espressamente autorizzati dispongono di diritti di amministrazione; ogni reimpostazione di un secondo fattore da parte dell'amministrazione viene registrata.

3.5 Controllo della separazione

I dati dei clienti sono separati logicamente per area di lavoro. Ogni percorso di lettura e scrittura nell'area riservata porta con sé questo vincolo; i report sono inoltre accessibili tramite il loro link (sezione 3.4).
Sviluppo ed esercizio funzionano in installazioni separate con database separati e utenti del database separati. L'utente di sviluppo non ha accesso al database di produzione. I dati reali dei clienti non vengono copiati nell'ambiente di sviluppo; lì lavoriamo con dati di esempio generati.
Per ogni ambiente lo scanner dispone di credenziali proprie con diritti solo sui dati di cui ha bisogno per i propri lavori. Non può leggere account, fatturazione o log.
Sul server web funzionano anche altri servizi dello stesso fornitore. Dispongono di database propri e di utenti del database propri senza accesso ai dati di questo servizio.

4. Cifratura, pseudonimizzazione e minimizzazione dei dati

4.1 Credenziali per la scansione dietro il login

Per questa funzione il Cliente memorizza il nome utente e la password di un account di prova. Sono i dati più sensibili del servizio e sono quindi protetti diversamente da tutto il resto:

Al momento della memorizzazione, il server web li cifra con la chiave pubblica del server di scansione (ECIES: X25519 con una chiave monouso per record, HKDF-SHA256, AES-256-GCM). La chiave privata esiste solo sul server di scansione. Server web, database e backup contengono solo testo cifrato; neppure noi possiamo leggerlo lì.
Ogni record è vincolato crittograficamente al proprio dominio. Se spostato su un altro dominio, la decifratura non riesce.
Per una scansione, il testo cifrato viene allegato al lavoro. Il server di scansione lo decifra e passa le credenziali al container di verifica solo tramite lo standard input, mai come argomento della riga di comando che sarebbe visibile negli elenchi dei processi. Non appena il server di scansione lo ha letto, il testo cifrato viene cancellato dal lavoro; un processo elimina eventuali residui al più tardi dopo un'ora.
Le credenziali non vengono mai visualizzate, mai registrate nei log, mai restituite tramite l'API e non vengono esportate. L'interfaccia mostra solo il primo carattere e la lunghezza del nome utente. La loro rimozione sovrascrive il testo cifrato.
Dietro il login lo scanner si limita a leggere: nessun invio, nessun test attivo, nessuno screenshot, nessuna pagina per disconnettersi, cancellare o disdire.

4.2 Ulteriore cifratura e hash

Password, codici di recupero, password dei portali clienti, chiavi API, codici di collegamento e di distribuzione, token “Resta connesso”, ID di sessione nell'elenco dei dispositivi e link di conferma e reimpostazione sono memorizzati solo come hash.
I segreti per il secondo fattore sono memorizzati cifrati (sezione 3.2).
Non dichiariamo una cifratura dell'intero database a riposo. I valori sensibili sono protetti singolarmente, come descritto sopra.

4.3 Minimizzazione dei dati fin dalla progettazione

Controllo di recapito: vengono letti solo gli header e al massimo i primi 8 KB del testo. Nel database finiscono solo l'ora, l'assegnazione, se del caso l'ID dell'invio di prova e il risultato della verifica di autenticità (SPF, DKIM, DMARC), mai il contenuto né un indirizzo completo del mittente. Il risultato di autenticità dell'e-mail più recente è conservato con il dominio e viene sovrascritto dal successivo; contiene l'indirizzo IP del server di posta che ha consegnato l'e-mail e il dominio e-mail del mittente. L'e-mail viene cancellata dalla casella di posta dopo l'elaborazione riuscita; se il recupero o la cancellazione non riescono, ciò avviene al successivo recupero riuscito.
Verifiche: la struttura dei moduli viene memorizzata con nomi dei campi, tipi ed etichette, attributi di obbligatorietà e visibilità, senza valori; lo scanner legge gli inizi dei campi nascosti precompilati (fino a 24 caratteri) e degli attributi data (fino a 60 caratteri) solo durante la verifica e non li memorizza. Gli screenshot della verifica completa non vengono oscurati; solo le verifiche nel browser coprono i campi di inserimento. Gli indirizzi dei destinatari dei moduli sono memorizzati solo come dominio. Gli invii di prova attivi contengono solo testi di prova contrassegnati, privi di dati personali.
Le estensioni per WordPress e TYPO3 trasmettono solo dati giornalieri e caratteristiche come l'inventario dei plugin e, per un plugin WordPress collegato, anche i domini dei link contenuti nei messaggi bloccati per la protezione collettiva (attivata per impostazione predefinita); nessun altro contenuto, nessun nome, indirizzo o indirizzo IP dei visitatori. I conteggi facoltativi degli errori dei moduli e dei campi sono disattivati per impostazione predefinita.
“Fix it for me”: il codice incollato viene trattato solo per la durata della richiesta e non viene memorizzato.
Badge: l'immagine del badge sui siti web dei clienti non imposta cookie e non avvia sessioni.
Le notifiche operative al telefono del gestore sono testi fissi senza variabili, quindi senza nomi, indirizzi o contenuti. Le notifiche di errore via e-mail al gestore contengono il testo grezzo del messaggio di errore, non ripulito e troncato a 400 caratteri; in singoli casi può contenere indirizzi o link.
Protezione collettiva: tra le estensioni dei Clienti vengono condivisi solo i domini dei link contenuti nello spam bloccato; lo scambio di reti IP è disattivato.
Localizzazione: il paese di un indirizzo IP viene determinato da un file di database locale; nessun indirizzo viene inviato a un servizio di geolocalizzazione.

5. Protezione contro l'uso improprio dello scanner

Lo scanner carica pagine di terzi con un browser reale. Senza protezione sarebbe uno strumento con cui qualcuno dall'esterno potrebbe raggiungere la nostra rete interna o altri obiettivi non pubblici (server-side request forgery). Esistono quindi due livelli indipendenti e l'isolamento di ogni singola esecuzione.

5.1 Esecuzione isolata

Ogni verifica viene eseguita in un proprio container, che viene poi rimosso. Funziona senza diritti di amministratore, senza capacità aggiuntive del sistema operativo e senza possibilità di elevare i privilegi. Il suo file system è in sola lettura, salvo piccole aree volatili.
Memoria, numero di processi e durata di esecuzione sono limitati; un'esecuzione che supera il tempo viene terminata.

5.2 Rete: due livelli

Primo livello, nello scanner: prima della scansione e poi per ogni singola richiesta del browser, compresi reindirizzamenti e contenuti incorporati, si verifica a quale destinazione si risolve l'indirizzo. Le reti private, locali, riservate e di documentazione (IPv4 e IPv6) vengono rifiutate, così come le porte diverse da quelle consuete per il web. Il browser non consente i service worker e le connessioni WebSocket vengono chiuse, perché entrambi potrebbero aggirare questo controllo.
Secondo livello, nella rete: i container funzionano in una rete propria. Le regole del firewall consentono da lì connessioni verso Internet solo sulle porte web; le connessioni verso reti private, compresa la nostra rete interna con server web e database, sono bloccate. Le eccezioni richieste dal processo di verifica stesso sono limitate al necessario e descritte nella nostra documentazione interna. Questo livello ha effetto anche se un nome si risolve diversamente solo dopo il primo controllo.

5.3 Richieste effettuate dal server web

Laddove il server web stesso richiede indirizzi di terzi – per la prova di controllo del dominio, per lo strumento header, per la ricerca di file esposti, per le richieste di polso, per le interrogazioni RDAP e per la verifica dei certificati, per i webhook e gli avvisi in chat e per il secondo punto di controllo facoltativo – si applicano le stesse regole: solo protocolli web, sulle porte web consuete (webhook e avvisi in chat solo tramite HTTPS sulla porta standard), solo indirizzi pubblici, una connessione solo esattamente all'indirizzo verificato in precedenza, affinché un nome non possa essere successivamente reindirizzato verso un obiettivo interno, reindirizzamenti non seguiti affatto oppure seguiti solo manualmente e ricontrollati ogni volta, limiti di tempo brevi; per la prova di controllo del dominio, per le richieste di polso e per il secondo punto di controllo nelle verifiche nel browser, anche una dimensione limitata della risposta.

5.4 Che cosa lo scanner non fa sui siti di terzi

Gli invii di prova attivi (al massimo cinque per verifica) esistono per i Clienti solo per i domini per i quali è stata fornita la prova di controllo (DNS, meta tag, file o estensione); l'unica eccezione sono le verifiche interne dei nostri domini di test e demo. Il nome host di un dominio con prova di controllo non può essere modificato, affinché la prova non passi a un altro host. Tutto il resto è passivo: lettura delle pagine come un visitatore.
Le verifiche nel browser arrivano fino al momento che precede l'invio e non attivano alcun ordine, pagamento o invio.
I domini presenti nell'elenco di opt-out non vengono verificati; il monitoraggio in corso termina con la successiva verifica programmata.

6. Integrità: trasmissione e inserimento

6.1 Trasporto

L'applicazione è raggiungibile da Internet solo tramite HTTPS; il browser riceve l'istruzione di utilizzare solo HTTPS per un anno (HSTS). I certificati vengono rinnovati automaticamente.
Ulteriori header limitano l'incorporamento dell'applicazione in pagine di terzi, l'indovinare i tipi di file e l'invio di moduli verso destinazioni di terzi. Una content security policy consente di eseguire nell'applicazione solo gli script che il server autorizza con la rispettiva risposta; i browser attuali non eseguono script o gestori di eventi iniettati nell'HTML.
La casella di posta del controllo di recapito viene consultata tramite una connessione cifrata con verifica del certificato.
I webhook possono essere firmati con un segreto del Cliente (HMAC-SHA256 con marca temporale), affinché il destinatario possa verificarne origine e integrità. Le richieste al secondo punto di controllo facoltativo sono firmate e, per le verifiche nel browser, anche le relative risposte.
Detto apertamente: le connessioni all'interno della nostra rete interna non sono cifrate in modo uniforme. Le credenziali per la scansione dietro il login restano cifrate in ogni fase (sezione 4.1).

6.2 Controllo degli inserimenti e log

Le azioni importanti negli account e nelle aree di lavoro (come login, modifiche a domini, destinazioni degli avvisi e diritti, cancellazioni, accessi dell'assistenza) vengono registrate nel registro delle attività con account, ora, indirizzo IP e paese, e cancellate dopo 365 giorni.
I registri degli accessi alle pagine conservati a fini di sicurezza e prevenzione degli abusi vengono cancellati dopo 60 giorni, i log degli errori dopo 90 giorni, i contenuti delle e-mail inviate dopo 30 giorni. I token di accesso negli indirizzi richiesti e nei referrer, come quelli dei link ai report o ai portali, compaiono nei registri degli accessi alle pagine solo in forma mascherata.
L'accettazione dei documenti contrattuali viene memorizzata con la versione visualizzata, il relativo checksum, l'ora, l'indirizzo IP e l'identificativo del browser.
I log probatori possono essere muniti di una marca temporale di un'autorità di marcatura temporale esterna; a essa viene inviato solo un checksum del contenuto, non il contenuto stesso.

7. Disponibilità e resilienza

7.1 Backup

Il database viene sottoposto a backup ogni notte. Un backup riceve il nome definitivo solo dopo la verifica del suo contenuto: completamento riuscito del programma di backup, almeno un record, tante tabelle quante ne ha il database e la riga di chiusura di un'esecuzione completa. I backup meno recenti vengono rimossi solo dopo un nuovo backup riuscito.
Ogni backup viene cancellato dopo 14 giorni. Il luogo di archiviazione si trova al di fuori di qualsiasi directory servita; un luogo all'interno del progetto viene rifiutato.
Test di ripristino: una volta alla settimana il backup più recente viene caricato in un database temporaneo, confrontato tabella per tabella con la produzione e poi cancellato. Il risultato viene memorizzato.
Se un backup o un test non riesce, viene inviata una notifica via e-mail e al telefono del gestore.
Ripristino dopo un incidente: se il database si guasta o i dati sono danneggiati, ripristiniamo il backup testato più recente. Le modifiche apportate dopo tale backup, di norma al massimo quelle di un giorno, possono andare perse; se un backup non è riuscito, corrispondentemente di più. Rieseguiamo quindi le richieste di cancellazione successive note (sezione 8). Non ci impegniamo a un determinato tempo di ripristino.
Limite, detto apertamente: i backup sono attualmente archiviati nella stessa sede del database e non sono cifrati separatamente. Proteggono da errori operativi, modifiche errate e dati danneggiati, non dalla perdita del server stesso. È pianificata una copia cifrata in una seconda sede (sezione 10).
Le credenziali per la scansione dietro il login sono contenute nei backup solo come testo cifrato; il segreto del secondo fattore solo in forma cifrata, con una chiave al di fuori del database.

7.2 Monitoraggio

Un processo di stato verifica ogni cinque minuti i componenti del servizio, compresi il database, la coda e il segnale di vita dello scanner, che lo scanner scrive regolarmente anche quando è inattivo. Se un componente si guasta, viene inviata una notifica; quando si riprende, un cessato allarme.
Sorveglianza incrociata: un processo di stato non può segnalare il guasto della macchina su cui è in esecuzione. Il server di scansione verifica quindi ogni minuto se l'applicazione risponde e, dopo diversi errori consecutivi, invia una segnalazione con un testo fisso al telefono del gestore. Viceversa, il server web sorveglia il segnale di vita dello scanner; la checklist di configurazione mostra se la sorveglianza incrociata è attiva.
Allarme errori: un tipo di errore mai verificatosi prima viene segnalato immediatamente una volta; un accumulo di errori attiva un solo segnale al telefono del gestore; una volta al giorno viene inviata una panoramica. In questo modo non veniamo a sapere di un errore per la prima volta da un Cliente.
Limite, detto apertamente: entrambi i server si trovano nella stessa sede. Un guasto dell'intera sede, ad esempio dell'alimentazione elettrica o della connessione Internet, non viene segnalato da alcun meccanismo di allarme ma notato da una persona.

7.3 Modifiche e distribuzione

Le nuove versioni vengono prima create e testate nell'ambiente di sviluppo separato. La distribuzione verifica tutti i prerequisiti prima che venga scritto il primo file, esegue le modifiche allo schema del database e lascia che le verifiche in corso terminino in modo ordinato prima che lo scanner si riavvii.
Per il percorso di un nuovo Cliente esiste uno smoke test tramite HTTP reale, che viene eseguito dopo i passaggi di versione. Non dichiariamo una suite di test automatizzati prima di ogni singola distribuzione.

8. Cancellazione e periodi di conservazione

Un processo di cancellazione notturno applica i periodi indicati nell'Informativa sulla privacy e nell'Accordo sul trattamento dei dati. Legge le stesse impostazioni da cui sono tratti i valori nei testi; per questi periodi testo e comportamento non divergono quindi.
I risultati delle verifiche, inclusi gli screenshot, vengono cancellati dopo 13 mesi (il più recente per dominio resta), i dati delle estensioni dopo 13 mesi, i registri di recapito degli avvisi dopo 90 giorni, le richieste di assistenza dopo 24 mesi.
La rimozione di un dominio cancella i dati del dominio, comprese verifiche, moduli, risultati, screenshot, report, lavori, destinazioni e registri degli avvisi, incidenti, dati di recapito, credenziali per la scansione dietro il login e prove.
La cancellazione di un account avviene immediatamente; le aree di lavoro senza altri membri vengono cancellate con 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. Fino alla scadenza dei rispettivi periodi restano: i log le cui voci conservano il vecchio numero di account, che non rimanda più ad alcun account esistente, compresa la voce di cancellazione, nonché le e-mail inviate, la prova della conclusione del contratto, le richieste di assistenza, i report delle verifiche dei potenziali clienti (fino a 90 giorni) e i dati di fatturazione presso Stripe; i dettagli si trovano nell'Informativa sulla privacy.
I dati cancellati restano nei backup fino alla loro scadenza dopo 14 giorni. Non avviene una cancellazione mirata all'interno di un backup; se un backup viene ripristinato, le richieste di cancellazione successive note vengono rieseguite manualmente.

9. Organizzazione e revisione

Persone: il servizio è attualmente gestito personalmente dal titolare. Altre persone ricevono accesso solo dopo un impegno alla riservatezza e solo nella misura necessaria, e trattano i dati solo su nostra istruzione (art. 29 e art. 32(4) GDPR).
Sub-responsabili del trattamento: vi ricorriamo solo dopo aver verificato le loro garanzie e sulla base di un contratto ai sensi dell'art. 28(4) GDPR, e li elenchiamo nella pagina Sub-responsabili del trattamento; i dettagli sono disciplinati dall'Accordo sul trattamento dei dati.
Violazioni dei dati personali: se una violazione dei dati personali riguarda dati trattati in qualità di responsabile, ne informiamo il Cliente senza indebito ritardo, se possibile entro 48 ore; i dettagli sono disciplinati dall'Accordo sul trattamento dei dati.
Segnalazione di vulnerabilità: accettiamo segnalazioni alla pagina Sicurezza e tramite il file /.well-known/security.txt.
Checklist di configurazione e di lancio: nell'area di amministrazione una checklist misura lo stato delle impostazioni rilevanti per la sicurezza, come backup, amministratori senza secondo fattore, configurazione della posta e segnale di vita, e mostra gli scostamenti.
Revisione delle presenti misure (art. 32(1)(d) GDPR): a ogni modifica significativa del servizio, dopo ogni incidente di sicurezza e comunque almeno una volta all'anno. In tale occasione valutiamo se le misure sono efficaci e ancora adeguate ai rischi, e registriamo il risultato in una nuova versione di questa pagina o, se non cambia nulla, con la data della revisione nella sezione 11. In modo continuativo, la checklist di configurazione e di lancio misura lo stato delle impostazioni che copre.
Audit esterni: attualmente non sono commissionati test di penetrazione esterni e non esistono certificazioni di sicurezza. Lo indichiamo qui affinché nessuno ne presuma l'esistenza.

10. Pianificato, non ancora attuato

Questi punti non sono misure a cui ci impegniamo finché non sono elencati qui come attuati in una nuova versione:

Backup in una seconda sede: una copia cifrata del backup notturno al di fuori del server, affinché anche una perdita totale del server non comporti una perdita di dati.
Secondo punto di controllo: la conferma indipendente delle verifiche nel browser da una seconda sede è predisposta nel servizio ma non configurata. Senza di essa non vi è conferma da una seconda sede.
Rafforzamento dell'amministrazione dei server: è in corso. Per i motivi indicati nella sezione 1 non ne pubblichiamo i dettagli.

11. Stato e versione

Versione 1.1 · Ultimo aggiornamento: 22 ottobre 2026 · in caso di discrepanze tra le versioni linguistiche, prevale la versione polacca anziché quella tedesca; nessun’altra modifica.
Versione 1.0 · Ultimo aggiornamento: 11 ottobre 2026 · prima versione come pagina separata; in precedenza Allegato 2 all'Accordo sul trattamento dei dati. Corretto rispetto all'allegato precedente: il test di ripristino è settimanale, i backup si trovano sullo stesso server, non viene eseguita una suite di test automatizzati prima di ogni distribuzione, le connessioni nella rete interna non sono cifrate in modo uniforme. Descritti per la prima volta: cifratura delle credenziali per la scansione dietro il login, isolamento dello scanner, sorveglianza incrociata e allarme errori.
Le modifiche vengono pubblicate con un nuovo numero di versione qui e nella panoramica Modifiche ai documenti contrattuali; per qualsiasi indebolimento delle misure si applica il preavviso previsto dall'Accordo sul trattamento dei dati.
In caso di discrepanze tra le versioni linguistiche prevale la versione polacca.

Come possiamo aiutarLa?