Checklist di audit di conformità per sistemi di trasferimento file
Checklist completa di audit di conformità per i sistemi di trasferimento file: controlli di sicurezza, gestione dati, log di accesso e requisiti normativi.
Un audit di conformità su un sistema di trasferimento file nel 2026 verifica se il deployment applica davvero i controlli dichiarati nelle policy aziendali. Una checklist operativa copre otto aree: crittografia (AES-256-GCM a riposo, TLS 1.3 in transito, ciclo di vita delle chiavi), controllo degli accessi (MFA, privilegio minimo, timeout di sessione), residenza dei dati (posizione dei server, sub-responsabili), logging e monitoraggio (audit trail per azione, integrazione SIEM), conservazione ed eliminazione (corrispondenza con la policy, cancellazione crittografica), due diligence di terze parti (SOC 2, ISO 27001 del fornitore), risposta agli incidenti (runbook testato, capacità di notifica 24-72 ore) e formazione degli utenti (aggiornamento annuale, contenuto per ruolo). Il Garante per la protezione dei dati personali e l'ACN (Agenzia per la Cybersicurezza Nazionale) valutano esattamente questi elementi durante le ispezioni.
Perché questo audit differisce da un audit IT generale
I sistemi di trasferimento file si trovano al confine: dentro il controllo aziendale quando il personale carica, fuori quando i destinatari scaricano. Un audit IT generale controlla la cifratura del disco e le regole firewall. Un audit sul trasferimento file deve seguire il file oltre quel confine. Il destinatario si autentica? La posizione di download è controllata? Il link può essere inoltrato? Cosa succede dopo la scadenza? L'audit mappa anche le normative che trattano il trasferimento file in modo specifico: GDPR Articoli 32 e 28, HIPAA 45 CFR 164.312(e) sulla sicurezza delle trasmissioni, PCI DSS Requisito 4 e SOX Sezione 404 sui requisiti dell'audit trail. Circoscrivere l'audit a queste clausole specifiche rende i risultati più nitidi.
Sezione crittografia della checklist
Verificare che i file a riposo siano cifrati con AES-256 in modalità GCM o CBC-HMAC autenticata. Verificare che il trasporto usi TLS 1.3 o TLS 1.2 con cifrari robusti (nessun RC4, 3DES o export-grade). Per i servizi con crittografia end-to-end, ispezionare la derivazione delle chiavi (PBKDF2 con almeno 600.000 iterazioni, o Argon2id con parametri calibrati) e confermare che le chiavi non raggiungano mai il server in chiaro. Controllare la cadenza di rotazione per le chiavi di lunga durata (90 giorni per le chiavi di sessione, annualmente per le master key su sistemi KMS). Confermare l'uso di HSM o KMS per le master key tramite log di audit o attestazione del fornitore. Richiedere la sezione sui risultati crittografici del report di penetration test.
Controllo degli accessi e autenticazione
Esaminare i metodi di autenticazione disponibili. L'MFA deve essere obbligatorio per gli account amministrativi e mittenti, con supporto per TOTP, WebAuthn o notifiche push. Il Single Sign-On tramite SAML 2.0 o OIDC deve integrarsi con l'IdP aziendale (Okta, Azure AD, Google Workspace). I timeout di sessione di 15-30 minuti per gli utenti inattivi sono in linea con la prassi standard. Per i destinatari: link protetti da password, verifica email per destinatario, oppure accesso basato su SSO. I link condivisibili senza controllo degli accessi sono un rilievo. Verificare il modello di ruolo amministrativo: la separazione tra system admin e audit reviewer impedisce a chi gestisce i log di manometterli.
Residenza dei dati e sub-responsabili
Confermare l'elenco documentato dei data center, le loro certificazioni (ISO 27001, SOC 2 Type II, SecNumCloud dove applicabile) e i Paesi in cui operano. Verificare che i backup rimangano nella regione richiesta. Ottenere l'elenco dei sub-responsabili e verificare la postura di conformità di ciascuno. Un fornitore ospitato su AWS Irlanda con un provider CDN statunitense ha un sub-responsabile CDN da investigare. Testare i controlli di localizzazione caricando un file e ispezionando le tracce di rete con Wireshark o gli strumenti di sviluppo del browser per verificare dove i byte effettivamente vanno. Le discrepanze tra le dichiarazioni di marketing e il comportamento osservato sono rilievi.
Logging, monitoraggio e alerting
Estrarre un campione di 30 giorni di audit log. Verificare che ogni caricamento, download, creazione di link, scadenza di link, azione amministrativa e autenticazione fallita sia presente. Controllare l'integrità hash-chained delle voci di log. Confermare che i log fluiscano verso un SIEM (Splunk, Sentinel, Elastic, Datadog) o siano esportabili tramite API. Testare il recupero: chiedere all'amministratore di produrre i log per un intervallo di date specifico e misurare il tempo di risposta. Esaminare le regole di alerting: volumi di download insoliti, accesso da geografie nuove, modifiche ai privilegi admin e raffiche di MFA falliti devono innescare un alert. Il silenzio su una qualsiasi di queste categorie è un rilievo. Verificare che la conservazione dei log soddisfi la regola più lunga applicabile (sei anni HIPAA, sette anni SOX).
Controlli di conservazione ed eliminazione
La policy e la pratica spesso divergono. Se la policy prevede 7 giorni di conservazione per i trasferimenti generici e 30 giorni per le project room, verificare che lo strumento applichi questi default e che non possano essere ignorati senza azione amministrativa. Testare l'eliminazione caricando un file, attendendo la scadenza, poi cercando di recuperarlo. Il file deve restituire un 404 o una pagina di link scaduto. Chiedere la meccanica di eliminazione: l'eliminazione a livello di file lascia intatte le copie di backup, mentre la cancellazione crittografica tramite distruzione della chiave soddisfa NIST SP 800-88 immediatamente. Confermare la funzionalità di legal hold simulando una richiesta e verificando che la cancellazione si sospenda.
Due diligence di terze parti
Raccogliere il report SOC 2 Type II più recente del fornitore, il certificato ISO 27001, le certificazioni di settore pertinenti, il sommario del penetration test e il Data Processing Agreement. Il report SOC 2 deve coprire almeno i Trust Services Criteria di Security e Confidentiality, e per uso privacy-intensivo anche Privacy. Controllare il nome dell'auditor (PwC, Deloitte, EY, KPMG, Schellman, BDO e società simili). Verificare che l'ambito includa il prodotto di trasferimento file, non solo l'IT corporate. Esaminare le eccezioni e le risposte del management. Un SOC 2 con più eccezioni non risolte nel periodo di audit è un segnale preoccupante.
Risposta agli incidenti e continuità operativa
Chiedere il piano di risposta agli incidenti. Deve nominare ruoli, metodi di contatto, livelli di escalation e template di notifica. Verificare che un esercizio tabletop o live si sia svolto negli ultimi 12 mesi e rivedere il report post-esercizio. Confermare il SLA di notifica delle violazioni nel DPA: 24-72 ore è lo standard per i clienti regolamentati. Testare inviando una domanda di sicurezza attraverso il canale pubblicato e misurando il tempo di risposta. Controllare la continuità operativa: frequenza dei backup, impegni RPO/RTO e failover testato.
Chiudere l'audit
Trasformare i rilievi in rimedi classificati. I rilievi critici (crittografia mancante, nessun DPA, nessun piano di risposta agli incidenti) bloccano l'uso continuato fino alla risoluzione. I rilievi alti (controlli di conservazione deboli, logging parziale) richiedono correzioni entro 30-60 giorni con controlli compensativi interinali. I rilievi medi e bassi alimentano il ciclo di audit successivo. Rivalutare almeno annualmente, più spesso per ambienti ad alto cambiamento. Archiviare il report di audit con le prove di supporto in uno store a prova di manomissione per almeno tutto il periodo della regola di conservazione più lunga applicabile.
HexaTransfer pubblica il proprio approccio alla crittografia, l'hosting UE e il comportamento di conservazione per gli acquirenti che vogliono fare audit prima dell'utilizzo. Provalo su hexatransfer.com — gratuito, senza account, max 10 GB.
Un audit di conformità non serve a produrre una pila di carta. Serve a verificare se il sistema di trasferimento file reggerebbe all'esame di un'autorità di controllo o al vaglio di un cliente. Percorrere ciascun controllo, testarlo rispetto alla normativa e raccogliere le prove. Il risultato è fiducia oppure un piano di rimedi. Entrambi sono utili. Nessuno dei due è facoltativo per gli acquirenti regolamentati nel 2026.
Invia file di grandi dimensioni in modo sicuro con crittografia end-to-end
Trasferisci file fino a 10 GB gratuitamente con crittografia end-to-end. Nessun account necessario. I tuoi file vengono crittografati nel browser prima del caricamento — nessun altro può leggerli.
Invia un file