Un accorciatore di URL sembra una superficie ridotta in una revisione del procurement. Due paragrafi nel questionario sulla sicurezza del fornitore, una rapida attestazione, una casella di controllo. Poi il team di sicurezza apre il diagramma dell'architettura e scopre che l'accorciatore si trova sul percorso di richiesta di ogni URL di campagna, ogni link di email transazionale, ogni reindirizzamento di codice QR. La revisione di due paragrafi diventa tre settimane di follow-up.
Questo post risponde alle domande che i team di procurement aziendali pongono effettivamente su SOC 2 Type II e HIPAA quando valutano un fornitore di tracciamento dei link. È scritto per chi compila il questionario e per chi ne revisiona la risposta.
In breve#
Elido ha la certificazione ISO 27001. Il SOC 2 Type II è in corso con completamento previsto nella seconda metà del 2026 — la finestra di audit è iniziata a febbraio 2026, la raccolta delle prove prosegue fino a luglio e il report Type II è atteso per la fine del Q4. HIPAA è supportato nei piani Business ed Enterprise con un Business Associate Agreement firmato; i controlli sottostanti sono gli stessi utilizzati per SOC 2.
La conformità al GDPR è distinta da SOC 2 e HIPAA ed è trattata nel GDPR per gli accorciatori di URL. Questo post si concentra sui framework di attestazione in stile US che guidano le revisioni del procurement aziendale.
Cosa dice effettivamente il SOC 2 su un accorciatore di URL#
SOC 2 è un report, non una certificazione. Un auditor indipendente (uno studio CPA negli US o un organismo di audit riconosciuto nell'EU) esamina un'organizzazione di servizi rispetto ai Trust Services Criteria dell'AICPA ed emette un parere. Il Type I documenta che i controlli sono progettati in modo appropriato in un dato momento; il Type II documenta che hanno operato efficacemente per un periodo — solitamente da sei a dodici mesi.
I Trust Services Criteria rientrano in cinque categorie. Ogni report SOC 2 copre la Security; gli altri quattro (Availability, Processing Integrity, Confidentiality, Privacy) sono inclusi a scelta dell'organizzazione di servizi in base alle necessità della clientela.
Security — la categoria sempre inclusa#
I criteri di Security coprono il controllo degli accessi, la gestione dei cambiamenti, il monitoraggio, la risposta agli incidenti e la valutazione dei rischi. Per un accorciatore di URL, i controlli più importanti sono:
- CC6.1 Logical access: chi può creare, modificare o eliminare un link breve, e come tale accesso viene concesso e revocato. L'audit traccerà utenti specifici dal record di onboarding delle Risorse Umane (HR) attraverso l'IdP (Ory Kratos per Elido) fino all'assegnazione del ruolo nel workspace, verificando che l'accesso sia stato rimosso entro la finestra stabilita dalla policy dopo la cessazione del rapporto.
- CC6.6 External access: come si autenticano gli utenti esterni (proprietari di domini personalizzati, consumatori di API, integrazioni partner) e quali scope ricevono. Il modello di token API con chiavi di idempotenza e scope per workspace è l'artefatto che l'auditor vuole vedere.
- CC7.2 Monitoring: cosa viene loggato, dove vanno i log e come emergono le anomalie. Per un servizio di redirect, i segnali rilevanti sono volumi di redirect insoliti per workspace, attivazioni di rate-limit all'edge e fallimenti di autenticazione.
- CC8.1 Change management: modifiche al codice dalla pull request fino al deployment, con separazione delle mansioni tra l'ingegnere che ha scritto la modifica e il revisore che l'ha approvata. L'audit campionerà le pull request ed esaminerà il registro delle approvazioni e dei deployment.
I criteri di Security sono anche il punto in cui SOC 2 prevede un piano di risposta agli incidenti documentato. Per un servizio di redirect, gli incidenti rilevanti sono la creazione non autorizzata di link, la manomissione della destinazione dei redirect e l'esfiltrazione di dati attraverso gli endpoint di esportazione degli analytics. Il runbook in /docs/runbooks/ copre il playbook per ciascuno di essi.
Availability — la seconda categoria più comune#
L'Availability copre gli impegni di uptime, la pianificazione della capacità e il disaster recovery. Per un accorciatore di URL, gli artefatti rilevanti sono:
- Un service-level objective documentato. L'SLO pubblicato di Elido è del 99,95% di disponibilità dei redirect per trimestre, con SLO separati per la dashboard (99,9%) e l'API degli analytics (99,5%).
- Prove di test di capacità. Il servizio di edge-redirect esegue test di carico continui in staging; l'audit cerca prove che l'inviluppo di capacità di produzione sia noto e monitorato rispetto all'SLO.
- Prove di backup e ripristino. Postgres esegue Patroni HA con point-in-time recovery; ClickHouse esporta quotidianamente su object storage; l'audit richiede il log dell'esercitazione di ripristino per dimostrare che il time-objective del ripristino sia raggiungibile.
- Documentazione del failover multi-regione. I tre POP (Frankfurt, Ashburn, Singapore) sono in configurazione active-active per i redirect; l'auditor leggerà il runbook di failover e il post-mortem dell'evento regionale più recente.
Confidentiality e Privacy — incluse selettivamente#
Confidentiality e Privacy aggiungono categorie che si sovrappongono alla postura GDPR. La maggior parte dei clienti aziendali nell'EU preferisce affrontare la privacy attraverso la documentazione GDPR (accordi con i responsabili del trattamento ai sensi dell'Articolo 28, valutazioni dell'impatto dei trasferimenti, il DPA pubblico) piuttosto che attraverso il SOC 2 Privacy. L'attuale ambito dell'audit SOC 2 di Elido include Security, Availability e Confidentiality. La Privacy viene affrontata separatamente attraverso la suite di documentazione GDPR su /trust.
Il motivo della suddivisione: SOC 2 Privacy si mappa sui Generally Accepted Privacy Principles dell'AICPA, progettati per i framework sulla privacy in stile US. Il GDPR è un quadro legale separato con i propri controlli. Unire i due in un'unica attestazione tende a indebolire entrambi.
Cosa dice effettivamente HIPAA su un accorciatore di URL#
L'HIPAA — l'Health Insurance Portability and Accountability Act, aggiornato da HITECH e dalla Omnibus Rule del 2013 — regola il modo in cui le Protected Health Information (PHI) vengono gestite dai covered entities (fornitori di assistenza sanitaria, pagatori, clearinghouse) e dai loro Business Associates.
Un accorciatore di URL diventa un Business Associate quando il link breve o i dati dietro di esso trasportano PHI. La domanda interessante è se ciò avvenga mai, e la risposta è più sfumata di quanto la maggior parte delle revisioni del procurement presuma.
Quando le PHI fluiscono attraverso un redirect#
Un link breve di per sé — s.elido.me/abc123 — non è PHI. L'URL di destinazione, i metadati del workspace e i tag della campagna non sono PHI nel caso generale.
La questione delle PHI risiede in tre punti specifici:
- URL di destinazione che contengono identificatori: un link breve che reindirizza a
https://provider.example/patient/12345/resultscontiene un identificatore del paziente nel percorso dell'URL. Tale URL di destinazione viene memorizzato dall'accorciatore ed è quindi PHI in senso stretto — anche se il link funziona perfettamente senza che nessuno presso l'accorciatore interpreti l'identificatore del paziente. - Parametri personalizzati aggiunti al momento del clic: se un redirect aggiunge un identificatore di sessione o di utente come parametro URL e tale identificatore è successivamente associabile a PHI, l'evento del clic diventa parte della catena PHI.
- Eventi clic con dati referrer: un evento clic include l'URL referrer. Se un referrer include accidentalmente un identificatore del paziente (una pagina di un portale paziente collegata in profondità che ha indirizzato l'utente al link accorciato), il campo referrer è PHI.
La maggior parte dei casi d'uso del marketing sanitario non genera PHI attraverso nessuno di questi canali. Un ufficio marketing di un sistema sanitario che gestisce campagne per vaccini antinfluenzali, eventi di benessere o contenuti sanitari generali produce redirect con destinazioni e referrer privi di PHI. Per quel carico di lavoro, il BAA è precauzionale, non architettonicamente necessario.
Per i carichi di lavoro che passano attraverso destinazioni PHI — portali dei pazienti, link di conferma appuntamenti, URL di consegna dei risultati di laboratorio — il BAA è obbligatorio e i controlli architettonici descritti di seguito devono essere attivi presso l'accorciatore.
La HIPAA Security Rule mappata su un servizio di redirect#
La HIPAA Security Rule (45 CFR Part 164, Subpart C) prescrive misure di salvaguardia amministrative, fisiche e tecniche. Per un servizio di redirect che gestisce PHI nelle destinazioni:
- Access controls (164.312(a)): identificazione univoca dell'utente, logoff automatico, crittografia delle ePHI in transito e a riposo. Elido impone identificatori utente univoci assegnati dall'IdP, timeout di sessione configurabili per workspace, TLS 1.3 su tutti gli endpoint esterni e crittografia a busta AES-256 a riposo per i relativi archivi dati.
- Audit controls (164.312(b)): registrazione ed esame dell'attività nei sistemi che contengono o utilizzano ePHI. Elido emette log di audit per la creazione di link, la modifica di link, i cambi di destinazione e l'esportazione di analytics in un archivio append-only a prova di manomissione. La conservazione dei log di audit è predefinita a 24 mesi nei piani Business+.
- Integrity controls (164.312(c)): protezione delle ePHI da alterazioni improprie. Gli URL di destinazione sono memorizzati con una cronologia a livello di riga; ogni modifica viene registrata con l'identità dell'autore e il timestamp, e il valore precedente rimane nella tabella della cronologia.
- Transmission security (164.312(e)): protezione delle ePHI in transito su reti aperte. TLS 1.3 su tutti gli endpoint dei redirect; HSTS preload; certificate pinning disponibile sui domini personalizzati.
Le salvaguardie amministrative e fisiche (formazione del personale, policy sulle sanzioni, controlli di accesso alla struttura) si sovrappongono pesantemente ai controlli di Security del SOC 2. Le stesse prove supportano entrambi gli audit, motivo per cui li eseguiamo secondo un programma di prove condiviso.
Cosa copre e cosa non copre il BAA#
Un Business Associate Agreement è un contratto ai sensi dell'HIPAA 164.504(e). Impegna il Business Associate a specifiche misure di salvaguardia, tempistiche di notifica delle violazioni e obblighi di trasferimento ai subappaltatori. Non cambia l'architettura sottostante; impegna il fornitore a gestire l'architettura in modo conforme ad HIPAA.
Il BAA standard di Elido, disponibile nei piani Business ed Enterprise, copre:
- Le quattro categorie di salvaguardia della HIPAA Security Rule applicate a tutti i dati che il cliente instrada attraverso il servizio di redirect.
- Notifica della violazione entro 60 giorni dalla scoperta, con tempistiche dettagliate di risposta agli incidenti coperte nel BAA e nel corrispondente runbook
/docs/runbooks/incident-response. - Trasferimento ai subappaltatori nominati (Hetzner, OVH, Postmark, Cloudflare, monobank Plata) sotto i propri BAA, ove applicabile. L'elenco attuale dei sub-responsabili è disponibile su
/legal/subprocessorsed è lo stesso utilizzato per la documentazione dell'Articolo 28 del GDPR. - Restituzione o distruzione delle PHI alla risoluzione del contratto, con una finestra di 30 giorni affinché il cliente possa esportare i dati prima della cancellazione.
Cosa non fa il BAA: non rende idoneo un piano che non prevede HIPAA. I piani Free e Pro non includono l'esecuzione del BAA. L'infrastruttura è la stessa in tutti i piani a pagamento; gli impegni legali no.
Il questionario di procurement — risposte da copiare e incollare#
La maggior parte dei questionari di procurement aziendali pone la stessa serie di domande. Le risposte seguenti sono quelle che forniamo direttamente, con link agli artefatti.
Disponete di un report SOC 2 Type II aggiornato? Certificazione ISO 27001 ottenuta; audit SOC 2 Type II in corso, con report Type II previsto per il Q4 2026. Le bridge letter e l'attuale certificato ISO 27001 sono disponibili sotto NDA tramite /trust. Il SOC 2 Type I è stato completato a novembre 2025; anche il report Type I è disponibile sotto NDA.
Firmerete il nostro BAA? Firmiamo il nostro BAA standard sui piani Business ed Enterprise. I BAA su carta del cliente vengono revisionati sui piani Enterprise; sono accettate modifiche comuni (finestre di notifica delle violazioni ampliate, attestazioni di salvaguardia aggiuntive, controlli sui subappaltatori specificati dal cliente). Contatta [email protected] per il testo standard o per avviare una revisione su carta del cliente.
Dove vengono memorizzati i dati? I clienti UE hanno come predefinito Francoforte (Hetzner FRA1, regione EU). I clienti US possono scegliere Ashburn (Hetzner ASH). Singapore (OVH SGP) è disponibile per i clienti APAC. La replicazione cross-region è opzionale per workspace; senza di essa, tutti i dati del cliente rimangono nella regione scelta. Il post sulla residenza dei dati descrive in dettaglio l'architettura di residenza.
Quale crittografia è in uso? TLS 1.3 in transito su tutti gli endpoint esterni (redirect, API, dashboard, analytics). Crittografia a busta AES-256 a riposo per il database Postgres primario, il cluster ClickHouse e l'object storage. Il KMS fornito dal cliente è supportato sui piani Enterprise tramite l'integrazione BYO KMS.
Come avviene il provisioning e il de-provisioning degli accessi? Single sign-on tramite SAML o OIDC via WorkOS; provisioning SCIM per il ciclo di vita degli utenti. Controllo degli accessi basato sui ruoli a livello di workspace con ruoli personalizzati disponibili su Enterprise. Il post su SCIM e SSO copre l'integrazione e i controlli del ciclo di vita.
Qual è il vostro processo di risposta agli incidenti? Runbook documentato con un SLA di risposta iniziale di 60 minuti, un SLA di aggiornamento tecnico di 24 ore e turni di incident commander designati. Le notifiche di violazione seguono le tempistiche nel nostro BAA e nel nostro DPA. L'indice completo dei runbook si trova in /docs/runbooks/.
Chi sono i vostri sub-responsabili? Cinque sub-responsabili nominati: Hetzner (infrastruttura, UE), OVH (infrastruttura, APAC), Postmark (email transazionali), Cloudflare (protezione DDoS sulle superfici di marketing pubbliche; non sul data plane dei redirect), monobank Plata (fatturazione per la clientela UE). L'elenco completo con i dettagli di contatto è disponibile su /legal/subprocessors.
Per quanto tempo conservate i dati dei clienti? Gli eventi clic vengono conservati per la durata del contratto più la finestra di esportazione di 30 giorni alla risoluzione, poi cancellati. La configurazione dei link viene conservata per la durata del contratto più la finestra di esportazione. Le metriche aggregate (conteggi di link per workspace, conteggi di clic al giorno, no PII) vengono conservate oltre il contratto per la fatturazione e la pianificazione interna della capacità.
Il file delle prove che un auditor vuole vedere#
Se sei un cliente aziendale che esegue il proprio audit SOC 2 ed Elido è un fornitore incluso nell'ambito, il tuo auditor chiederà probabilmente prove relative ai controlli CC9.2 (gestione dei fornitori) e CC1.4 (impegni). Il fascicolo del fornitore dovrebbe contenere:
- Il nostro certificato ISO 27001 attuale (rinnovabile annualmente).
- Il nostro report SOC 2 Type I e la bridge letter per il SOC 2 Type II (disponibili sotto NDA).
- I nostri DPA e BAA firmati, ove applicabile.
- Il nostro elenco dei sub-responsabili e le date di eventuali modifiche.
- Uno snapshot della nostra pagina pubblica sulla sicurezza su
/truste la versione più recente della privacy policy. - La nostra cronologia delle notifiche di violazione (la cronologia pubblica è vuota — il log interno viene revisionato durante il procurement sotto NDA).
Il fascicolo delle prove viene creato una volta per ogni ingaggio del cliente e aggiornato annualmente. L'elenco sopra riportato è il set standard; le aggiunte specifiche dell'auditor sono gestite caso per caso.
Cosa è veramente difficile#
Due cose sono veramente difficili riguardo a SOC 2 e HIPAA per un servizio di redirect, e le menzioniamo perché la conversazione di procurement solitamente le fa emergere prima o poi.
Le prove di monitoraggio continuo per i POP edge non sono banali. Il data plane dei redirect elabora elevati volumi di traffico in tre regioni e l'auditor vuole prove che il monitoraggio operi continuamente, non solo per campionamento. L'approccio attuale utilizza redirect sintetici da ogni regione ogni minuto, con lo stato degli avvisi acquisito in un log a prova di manomissione. Il costo di questo monitoraggio è reale e il design è passato attraverso tre iterazioni per ottenere il giusto rapporto segnale-rumore. La guida all'osservabilità nella documentazione copre la configurazione attuale; l'ADR sottostante si trova in /docs/adr/0024-sla-monitoring.md.
Le tempistiche di notifica delle violazioni HIPAA sono più strette rispetto al GDPR. HIPAA richiede la notifica alle persone interessate entro 60 giorni dalla scoperta; per le violazioni che colpiscono oltre 500 persone, sono necessarie notifiche aggiuntive all'HHS e ai media. Il GDPR concede 72 ore all'autorità di controllo, ma la tempistica di notifica alle persone interessate è "senza indebito ritardo". Per una violazione multi-giurisdizionale, la tempistica HIPAA spesso prevale. Ci impegniamo a rispettare la tempistica HIPAA per impostazione predefinita per qualsiasi incidente che tocchi i dati dei clienti instradati negli US, e il nostro runbook di risposta agli incidenti lo riflette.
Letture correlate#
- GDPR per gli accorciatori di URL: cosa vuole vedere realmente il tuo DPO — il pilastro per il cluster della conformità.
- Residenza dei dati UE per il marketing analytics — l'architettura di residenza e le opzioni di pinning.
- Schrems II e i tuoi pixel di tracciamento — contesto sulla valutazione dell'impatto dei trasferimenti.
- SCIM e SSO per gli strumenti di marketing — i controlli di accesso che soddisfano il CC6.1.
- Attribuzione dei clic dopo Safari ITP — post adiacente sulle restrizioni della privacy lato browser.
- Walkthrough operativo: la guida alle prove SOC 2 nella documentazione — come funziona la raccolta delle prove nella pratica.
- Superficie del prodotto:
/solutions/compliancee/solutions/enterpriseper l'idoneità dei piani e la mappatura delle funzionalità.