HIPAA per aziende italiane:
cosa serve davvero

In breve: se la tua azienda tratta dati sanitari per conto di clienti statunitensi — software, servizi linguistici, life science, hosting — sei con ogni probabilità un Business Associate ai sensi dell’HIPAA (Health Insurance Portability and Accountability Act), la legge federale USA sulla privacy sanitaria. Gli obblighi arrivano via contratto: serve un BAA (Business Associate Agreement), non serve spostare i dati negli Stati Uniti e la «certificazione HIPAA» non esiste. Ecco cosa serve davvero — e perché chi ha già un sistema ISO 27001 parte avvantaggiato.

HIPAA in due parole: perché tocca anche le aziende italiane

L’HIPAA protegge le PHI (Protected Health Information): informazioni sanitarie riconducibili a una persona — cartelle cliniche, referti, dati di studi clinici e di farmacovigilanza, dati di fatturazione sanitaria. In forma elettronica si parla di ePHI. Le regole operative stanno in due regolamenti attuativi: la Privacy Rule (usi e divulgazioni consentiti) e la Security Rule (misure di sicurezza per le ePHI), codificati in 45 CFR Parts 160 e 164.

La legge si applica direttamente alle Covered Entity — provider sanitari, piani assicurativi e clearinghouse statunitensi — e ai loro Business Associate: chiunque crei, riceva, conservi o trasmetta PHI per loro conto. La catena non si ferma al primo anello: il subcontractor di un Business Associate è a sua volta soggetto agli stessi obblighi.

HIPAA non è una legge italiana, e l’OCR (Office for Civil Rights) dell’HHS (Department of Health and Human Services) non ha giurisdizione diretta su un’azienda di Piacenza o di Milano. Il vincolo arriva però per via contrattuale — e di mercato: senza le garanzie HIPAA messe nero su bianco, il cliente americano non può affidarti dati sanitari.

Il BAA: il contratto che fa scattare gli obblighi

Il Business Associate Agreement è il contratto che HIPAA impone tra Covered Entity e Business Associate — e, a cascata, tra Business Associate e i suoi subcontractor. Contiene gli elementi che la normativa richiede espressamente: usi e divulgazioni consentiti delle PHI, salvaguardie di sicurezza adeguate, obbligo di segnalare al cliente violazioni e incidenti, condizioni per ricorrere a subcontractor (a loro volta vincolati per iscritto) e restituzione o distruzione dei dati alla fine del rapporto.

L’esempio tipico: un ospedale o una società life science statunitense (Covered Entity o Business Associate a sua volta) affida a un’azienda italiana servizi che toccano dati sanitari — traduzioni mediche, sviluppo software, analisi dati, hosting di applicazioni. L’azienda italiana firma il BAA con il cliente; i suoi fornitori che vedono quei dati firmano con lei. È la stessa logica di trasparenza che applichiamo al nostro elenco pubblico dei subfornitori: ogni anello della catena risponde di quello successivo.

Il momento giusto per firmarlo è prima che le PHI inizino a circolare: i clienti USA strutturati lo chiedono in fase di due diligence, insieme alle evidenze sui controlli di sicurezza.

Mito da sfatare: i dati devono stare negli USA

HIPAA non contiene alcun requisito di localizzazione dei dati. Le linee guida dell’HHS sul cloud computing non vietano la conservazione fuori dagli Stati Uniti: chiedono che il cloud service provider firmi un BAA e che i rischi — inclusi quelli legati alla giurisdizione — siano coperti dalla risk analysis.

Per un’azienda italiana, tenere i dati in datacenter europei è spesso la scelta più sensata: il trattamento svolto in UE resta comunque soggetto al GDPR, e una sola residenza dei dati semplifica entrambi i fronti. HIPAA e GDPR convivono senza conflitto — il primo arriva via contratto, il secondo per legge. Se un cliente americano chiede la residenza negli USA, è una sua policy interna o una clausola negoziale: legittima, ma non un obbligo HIPAA.

Security Rule: il mapping con ISO 27001, 27017 e 27018

La Security Rule organizza le misure per le ePHI in tre famiglie: safeguard amministrative (risk analysis, formazione, gestione del personale e degli accessi, incident response), fisiche (accesso a strutture, postazioni e supporti) e tecniche (controllo degli accessi, audit, integrità, cifratura in transito).

Chi opera con un ISMS ISO/IEC 27001 ha già la macchina organizzativa: valutazione del rischio, politiche, controllo accessi, gestione degli incidenti, continuità operativa. I controlli cloud di ISO/IEC 27017 e la protezione dei dati personali nel cloud di ISO/IEC 27018 coprono il terreno specifico dei servizi cloud. La guida ufficiale per il mapping è NIST SP 800-66 Rev. 2 (febbraio 2024), che traduce la Security Rule in controlli di sicurezza concreti: è il punto di partenza per confrontare i requisiti HIPAA con il proprio Statement of Applicability.

Restano requisiti specifici HIPAA senza equivalente diretto ISO: il BAA, il principio del minimum necessary (trattare solo il minimo di PHI necessario allo scopo) e la notifica delle violazioni alla Covered Entity secondo la Breach Notification Rule: senza ritardo ingiustificato e comunque entro 60 giorni dalla scoperta — un tetto normativo che i contratti tipicamente stringono. Sono gli stessi punti su cui un audit di un cliente USA si concentra per primo.

L’aggiornamento della Security Rule: MFA e cifratura verso l’obbligo

Il 6 gennaio 2025 l’HHS ha pubblicato nel Federal Register la proposta di revisione della Security Rule (NPRM, Notice of Proposed Rulemaking): la prima modifica sostanziale dal 2013. I punti chiave: autenticazione a più fattori obbligatoria, cifratura delle ePHI a riposo e in transito, eliminazione della distinzione tra specifiche «required» e «addressable» (oggi molte misure sono di fatto negoziabili, domani no), inventario tecnologico con mappa dei flussi di ePHI nella rete e verifica di conformità annuale.

Lo stato a giugno 2026: la regola finale era attesa per maggio e non è ancora stata pubblicata. La direzione però è chiara, e conviene progettare già sui requisiti proposti: MFA e cifratura sono comunque buona pratica — e per chi rientra nel perimetro NIS2 sono in larga parte già obblighi di legge.

Stack cloud e HIPAA: cosa copre Microsoft, cosa resta a te

Microsoft include gli impegni da Business Associate nel proprio Data Protection Addendum: i servizi Azure e Microsoft 365 possono quindi ospitare ePHI nell’ambito del BAA Microsoft, anche su region europee — quelle che usiamo noi offrono 3 availability zone ciascuna.

Attenzione però al perimetro: il BAA del cloud provider copre l’infrastruttura, non il modo in cui la usi. Configurazione degli accessi, autenticazione a più fattori, cifratura, conservazione dei log di audit, formazione del personale e gestione degli incidenti restano responsabilità di chi eroga il servizio al cliente finale — è il modello di responsabilità condivisa che vale per tutti i servizi cloud. Firmare il BAA giusto e poi lasciare un account amministrativo senza MFA è il modo più rapido per trasformare la conformità in carta.

Sovranità digitale: una considerazione controcorrente

Il dibattito europeo sulla sovranità digitale scivola spesso nel massimalismo: «serve software europeo», «via dai provider americani», come se gli Stati Uniti fossero un avversario strategico. La realtà industriale è meno ideologica: su cloud, sicurezza e sanità digitale la specializzazione mondiale si concentra in larga parte negli USA — dove peraltro lavorano moltissimi professionisti italiani — e una quota enorme dell’economia B2B italiana vive di rapporti transatlantici, incluse le tante aziende italiane controllate da gruppi americani.

Per queste realtà, il timore dei «dati in Europa ma governati da leggi americane» è spesso un falso problema: se la capogruppo è statunitense, la giurisdizione USA sul gruppo esiste comunque, per struttura societaria, prima ancora che per collocazione dei dati. E l’Italia affida agli Stati Uniti tecnologie ben più critiche di un gestionale in cloud: i caccia F-35, la cui logistica e i cui aggiornamenti software dipendono da infrastrutture americane — il dibattito pubblico è arrivato a discutere di un presunto «kill switch», ufficialmente smentito. Pretendere il purismo europeo sul SaaS mentre la difesa vola su piattaforme USA dice molto su quanto la discussione sia diventata più ideologica che tecnica.

Pragmatismo non significa disattenzione: conosciamo gli effetti del CLOUD Act, eseguiamo Transfer Impact Assessment (TIA) quando i trasferimenti lo richiedono e seguiamo da vicino Data Act e AI Act europei. Ma la residenza dei dati resta uno strumento, non una bandiera: proponiamo datacenter europei quando semplificano contratti e conformità — GDPR in testa — e lavoriamo serenamente dentro catene societarie e normative americane quando è questo che il cliente richiede, senza sposare una sola filosofia o tifoseria. HIPAA, del resto, funziona esattamente così: segue i contratti, non i confini.

Come AtWorkStudio aiuta

Prima la trasparenza: la certificazione HIPAA non esiste, e nessun fornitore serio può dichiararsi «HIPAA certified». Quello che facciamo è portare sul terreno HIPAA il metodo del nostro sistema di gestione certificato: risk analysis, misure tecniche e organizzative, documentazione verificabile, catena contrattuale con i subfornitori. Serviamo già realtà italiane con utenti negli Stati Uniti su infrastrutture cloud gestite.

Operiamo da Piacenza dal 2000. Siamo certificati ISO/IEC 27001, 27017, 27018 e ISO 9001, qualificati ACN (Agenzia per la Cybersicurezza Nazionale) per servizi cloud, membri di Clusit (Associazione Italiana per la Sicurezza Informatica) e associati a Confindustria Piacenza nel cluster RICT.